返信遅くなりすいません。

さくらのどのプランをお使いですか？

レンタルサーバーであれば、普通に https でアクセスすれば良いだけです。
ただ、 http でアクセスが来た人も https にリダイレクトさせたい場合は

SSL Redirect Configuration
http://www.concrete5.org/marketplace/addons/ssl-redirect-configuration/
というアドオンがあります。

もしも設定に失敗するようなことがあって、アクセスできなくなれば
/application/config/generated_overrides/ssl_redirect_conf/https.conf
のファイルを削除すれば大丈夫です。

うちも「さくらスタンダード」で難儀しております。
5.6のときは.htaccessでhttpsにリダイレクトするだけで良かったのですが、
5.7になってから、リダイレクトループが発生したり、ログイン後httpsで表示しているのにhttpへのリンクがあったり…
（現在、発生状況を整理中ですが、既に公開しているサイトなので夜中にしか作業が出来ず整理も難航しております）

とりあえず、5.6は絶対パスでリンクしていて、5.7はURLでリンクしているせいかも？と検討をつけておりますが、どこを治せばよいのやら…

1カ所、気になるところがありましたので報告します。
さくらのSNI SSLを使ってる場合、
_SERVER["HTTPS"] = on
_SERVER["SERVER_PORT"] = 80
という状態になります。
※httpsはプロクシとして動作、だそうです。
http://help.sakura.ad.jp/app/answers/detail/a_id/2325
※添付はphpinfoの該当部分です。

これが/concrete/vendor/zendframework/zend-feed/src/PubSubHubbub/AbstractCallback.phpの241行目〜に抵触して不本意な動作を生むのかなぁ…とか思ったりします。

なにかの参考になれば幸いです。

プロキシを信頼する設定を行ってみてください。config/concrete.php のサンプルコードです。

http://gist.github.com/hissy/bdb2c63c0b8f29ca1494

PHPの配列の取り扱いについてご存知でなければ、下記URLを参考にしてください。

http://concrete5-japan.org/help/5-7/recipes/config/

concrete5はhttpsは443でやりとりすることになっている。。という情報が書き込みされてますが、間違いです。調整は可能ですので頑張ってください。

ほほう。なるほど・・・・。
ポート番号が、https でも 80 番ですか・・・。

それだとちょっと手ごわいかもですね・・・。
concrete5 では、https は 443 番でやりとりすることになっているのですが・・・

ちょっと、この修正を試してもらうことはできますか？

http://github.com/concrete5/concrete5/pull/3698/files


//**
* ----------------------------------------------------------------------------
* Set trusted proxies and headers for the request
* ----------------------------------------------------------------------------
*/
if($proxyHeaders = $config->get('concrete.security.trusted_proxies.headers')){
foreach($proxyHeaders as $key => $value) {
Request::setTrustedHeaderName($key, $value);
}
}
if($trustedProxiesIps = $config->get('concrete.security.trusted_proxies.ips')) {
Request::setTrustedProxies($trustedProxiesIps);
}

のコードを、

/**
* ----------------------------------------------------------------------------
* Legacy Definitions
* ----------------------------------------------------------------------------
*/

の上に移動させてみてください。

あと、

http://github.com/katzueno/concrete5-install-shell-scripts/blob/master/config/cloud9.concrete.php

を /application/config/concrete.php
として保存してみてくれませんか？

Katz Ueno様
ありがとうございます。
試してみたところ、動作に変化はありませんでした…。

さくらのSNI SSLの挙動について整理してみました。
・PHP 5.6.18 (cgi-fcgi)
・concrete5 - 5.7.5.6
・キャッシュ全て無効
・プリティーURL有効

a）https://mydomain で閲覧
　基本的に大丈夫。ただし、ページ内のリンクが
　https://mydomain/contents/
　のように最後にスラッシュがついていると
　http://mydomain/contents　←SSL/TLSなし
　に飛ばされます。

b）https://www.mydomain で閲覧
　こちらもwww無しと同様に基本的に大丈夫。
　ただ、上記同様、最後にスラッシュがついていると
　https://www.mydomain/contents/
　から
　http://mydomain/contents　←SSL/TLSなし、wwwなし
　に飛ばされます。

c）https://mydomain でログイン
　ID/PW入力後、ログイン状態でhttp://mydomain（SSL/TLSなし）に飛ばされます。
　改めてURLにhttps://を入力してもログイン状態は保てたままですが、
　TOPページ「https://mydomain/」以外では、ツールバーの管理画面ボタンが「http://mydomain/（SSL/TLSなし）」をリンクしており、ツールバー右の管理用ドロップダウンメニューが表示されない状態です。
　また、TOPページにて管理用ドロップダウンメニューを表示させた際も、サイトマップ等メニュー項目のリンクが全てSSL/TLSなしを指しているので、項目を選ぶとSSL/TLSが外れます。

d）https://www.mydomain でログイン
　ログイン画面、フォームのpost先が「https://mydomain（wwwなし）」となっており、ID/PW入力後は上記c）同様、ログイン状態でhttp://mydomain（SSL/TLSなし　wwwもなし）に飛ばされます。
　改めてURLにhttps://www.を追加した場合は当然ながら非ログイン状態となります。
　そのままwww.無しの状態での作業は上記c）と同様です。

こんな感じになりました。

※上記のスラッシュ問題、concrete5をルートにインストールした場合はペー
ジ内のリンクを修正することで解決できるのですが、
http://www.mydomain/concrete5/
のように下位フォルダにインストールした場合は、また厄介なことに…。

Virtualboxで「模擬さくらサーバー」を立て、フルサイト（＝Elemental）
をインストールしてテストしてみました。
ホームへのリンクが
http://www.mydomain/concrete5b/index.php?cID=1
となっているとき（つまりデフォルト）、書き出される a hrefは
http://www.mydomain/concrete5 ←最後のスラッシュ無し
を指しています。
結果としてmod_dirが発動し、wwwなしのhttpページ（http://mydomain/concrete5/）へジャンプします。
（ルートにインストールした場合は、最後スラッシュ無しでも正常に動作します）

ポート問題に加え、プリティーURLの「最後のスラッシュは全部取っちゃうぞ」行動が原因の一つを担っているような気がしました。

申し訳ありませんが引き続きよろしくお願いいたします。

aniyaさま

プリティーURLの「最後のスラッシュは全部取っちゃうぞ」行動が原因の一つ

URL の最後にスラッシュが付いていれば問題ないということでしょうか？

さくらインターネットでの SSL 化は他人事ではなく、何とか解決できればいいですね。

nipper様

ホームへのリンクに関しては、スラッシュが付いていればmod_dirが発動せず、問題解決となると思います。

ただ、一番の問題は「https時のポートは443固定」という前提でコアの部分が処理されており、それが原因で諸々の不具合が出ている事だと思います。

aniyaさま

スラッシュを付けるのは、application > config > generated_overrides > concrete.php に

'seo' => array(
'trailing_slash' => true,
)

を記述すればいけませんか？

Katz Ueno様
aniya様
お世話になっております。

当初の質問者がしばらくノーリアクションで大変申し訳有りません。
並びにご尽力誠に恐れ入ります。
私もいろいろ状況を整理してみましたが、anjya様とほぼ同じ挙動でした。
(むしろ同じ問題を共有できて非常に心強いです)

私もいろいろ試してみますが、引き続きお付き合いいただけると非常に助かります。

さくらの常時SSL化ですが…未だ解決にいたっておりません(T-T)
さらに新たな問題発覚！といった状態です。

→新たな問題その1
　レイアウト機能（ブロックの横並び）を使ったページをhttpsで表示するとレイアウトが崩れる

→新たな問題その2
　リンクをライトボックス風に表示させる設定にした場合、httpsで表示するとリンク先が表示されない。

両方ともhttpだと普通に表示されるので、内部読み込みのcssがhttpで呼ばれているせいでは？と予想しています。

これってソースの各所にある
if (('https' === $this->scheme && $this->port === 443)
のような記述を443から80に書き換えれば解決するのでしょうか？
※もっと簡単な解決方法があれば是非教えてください。

よろしくお願いします。

追伸
shideto様
一緒に頑張りましょ〜〜

常時SSL について、返信が滞ってすいません。

取り急ぎ・・・。
最新バージョンの 5.7.5.8 ではどうですかね？

初めまして
SSL化で詰まってまして
似ている問題でしたので、
こちらの方に質問させていただきました。


・お使いのサーバー
　　さくらインターネット
　　ビジネスコース

・お使いの concrete5 のバージョン (下記の環境情報があればなお可)

# concrete5 Version
Core Version - 5.7.5.8
Version Installed - 5.7.5.8
Database Version - 20160412000000

# concrete5 Packages
Spacer (0.9.3).

# concrete5 Overrides

長いので省略しました

# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).

# Server Software
Apache/2.2.31

# Server API
cgi-fcgi

# PHP Version
5.4.45

# PHP Extensions
cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, gd, gettext, gmp, hash, iconv, json, libxml, mbstring, mcrypt, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, Reflection, session, SimpleXML, snmp, soap, SPL, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib.

# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5



・お困りの内容を、できるだけ詳しく

独自SSLで　現在　https://url 　http://url 　
両方でページは表示しています。同じフォルダーのデータを読みに行っています。

ページ全体を全て　httpsの常時SSLしたいのですが

ページ全体のSSL対応は　「URLとリダイレクト」のところの
SSL URL のところにURLを入れてるのですがこれだけでいいのでしょうか？

http で入力された場合でも　自動的にhttpsにするにはどこをさわればよいのでしょうか？

htaccessは
プリティーURLの設定してますので

DirectoryIndex index.php index.html index.cgi index.shtml
<IfModule mod_rewrite.c>
RewriteEngine On
# RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
# RewriteRule ^(.*)$ https：//www.raytron.co.jp/ $1 [R=301,L]
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteRule . index.php [L]
</IfModule>
httpsが引用にしてもsが外れますので全角の：に置き換えてます

コメントアウトを外すと
全てhttps://　になるのですが
メールフォームはボタンを押すとエラーになります、
ログインもできなくなります。

コメントアウトした場合でも
　https://　で表示した
メールフォームや　ログインページなど　文字を入力して
ボタンを押すと
http に戻って暗号化されないページに移動します。
MAC サファリでは　暗号化されないとアラートが出るので。
されてないのだと思います

この症状はさくらだけの症状で、他のサーバでは起こらない現象なのでしょうか？

フォームブロックのページのみSSL対応でもよいので解決策があれば

サーバのこととか、よくわかりませんので
解決方法のヒントがあればお教え願いませんでしょうか？
乱暴な質問ですいません。

tokami様
5.7.5.8でも不具合が出るとの情報ありがとうございます。

ページ全体のSSL対応は　「URLとリダイレクト」のところの

これはカノニカルURLの設定となりますので、ちょっと違います。
具体的には「https://www.raytron.co.jp」「https://raytron.co.jp」の両方でアクセス可能な場合に、どちらのURLを用いて表示するか？を設定する項目となります。

http で入力された場合でも　自動的にhttpsにするにはどこをさわればよいのでしょうか？

concrete5にその設定は無く、Katz Ueno様が上の方で紹介している「SSL Redirect Configuration」というアドオンを使うか、tokami様が記述しているようにサイト側の.htaccessで設定します。

ただ…それで不具合が出ているのでこのトピックが未解決となっております。

.htaccessのコメントアウトを外してエラーになる件は、さくら側でポート番号80を返しているのが原因です。

会話形式で説明するとこんな感じです。
1）さくら「httpをhttpsに転送します。https通信ですがポート番号は80です」
2）con5「httpsでの接続要求がありましたが、ポート番号が443でないとhttpsとは認められないので、httpとして処理します」
3）さくら「httpをhttpsに転送します…（以下同様）」
といった感じでループが発生しエラーとなります。

一般的なhtml/cssページを処理するだけの場合はhttpsでも接続可能ですが、
フォームブロックやログイン、レイアウト機能、リンクのライトボックス風表示など、動的に内部処理が行われるページの場合は、上記ループが発生してエラーとなるようです。

.htaccess該当部分をコメントアウトしても、フォーム入力時にhttpに戻って暗号化されないページに移動する現象も上記ループと同じ原因です。con5側がhttps通信と認めていないのでhttpに飛ばされます。

この症状はさくらだけの症状で、他のサーバでは起こらない現象なのでしょうか？

https通信時、ポート番号が443になる一般的なサーバーの場合はこの現象は起こりません。
※さくらのhttpsはプロクシとして80番ポートで動作しています。
http://help.sakura.ad.jp/app/answers/detail/a_id/2325/~/ssl%E5%88%A9%E7%94%A8%E6%99%82%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9

またレガシー（5.6）では.htaccessの設定だけでhttps専用にすることができ、バグも発生しません。

フォームブロックのページのみSSL対応でもよいので解決策があれば

私の場合、フォームブロックを使わずcon5外部にメール送信専用phpを設置して対応しました（前述の通り、内部処理を行わないhtml/cssページならばバグが発生しないので）。

参考になれば幸いです。

aniya様

返答ありがとうございます。
わからなかったことが、解決できて助かりました。

concrete5にその設定は無く、Katz Ueno様が上の方で紹介している「SSL Redirect Configuration」というアドオンを使うか、tokami様が記述しているようにサイト側の.htaccessで設定します。

SSL Redirect Configurationはエラーが出て動きませんでしたので
htaccessに書き込みました。

対策として、さくらサーバで解決が無理な場合は
メールフォームページのみ静的HTMLで作って別にあげようと思っています。

後、hisikawa様が下記に書いてくれている方法を、週明けに試してみようかと思います。

状況を確認したいので、下記URLのPHPを application/bootstrap/app.php に追記していただいて、 /ccm/request_test というURLにリクエストしていただければ助かります。concrete5が、現在のリクエストをどのように判断しているか（HTTPと思っているのか、HTTPSと思っているのか）がわかります。

http://gist.github.com/hissy/6d0850560648021563965b0e64f0d92e

takuro hishikawa様
ありがとうございます。
早速表示させてみました。
※ドメインとIPは一部伏せてあります。
※219.98.***.***は全て同一のIPアドレスです。

■httpの場合：
Application environment:
production
Client IP:
219.98.***.***
Host:
mydomain.com
Port:
80
Scheme:
http
Secure:
false
Canonical URL:
http://mydomain.com/
Get all headers:
array(8) {
["Host"]=>
string(11) "mydomain.com"
["Connection"]=>
string(10) "keep-alive"
["Accept"]=>
string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
["Upgrade-Insecure-Requests"]=>
string(1) "1"
["User-Agent"]=>
string(120) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
["Accept-Encoding"]=>
string(19) "gzip, deflate, sdch"
["Accept-Language"]=>
string(23) "ja,en-US;q=0.8,en;q=0.6"
["Cookie"]=>
string(42) "CONCRETE5=f53affed91f1cfa541ca921eb3c644c6"
}


■httpsの場合：
Application environment:
production
Client IP:
219.98.***.***
Host:
mydomain.com
Port:
80
Scheme:
http
Secure:
false
Canonical URL:
http://mydomain.com/
Get all headers:
array(8) {
["Host"]=>
string(11) "mydomain.com"
["Accept"]=>
string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
["Upgrade-Insecure-Requests"]=>
string(1) "1"
["User-Agent"]=>
string(120) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
["Accept-Encoding"]=>
string(23) "gzip, deflate, sdch, br"
["Accept-Language"]=>
string(23) "ja,en-US;q=0.8,en;q=0.6"
["X-Sakura-Forwarded-For"]=>
string(14) "219.98.***.***"
["Connection"]=>
string(5) "close"
}

よろしくお願いいたします。

なるほど、通常のバランサー越しのアクセスなどであれば、X-Forwarded-Proto などのヘッダでオリジナルのスキーマが渡されるので対処可能なのですが、さくらの場合は全くナシですね。正直、これはヒドい…。渡されているヘッダのうち、使えそうなものは HTTP_X_SAKURA_FORWARDED_FOR ヘッダのみなので、コレがある場合のみ、必ずHTTPSだ、という判断をするしかないかなと思います。

ということをするコードがこちらです。
http://gist.github.com/hissy/d9063ade6cfb6471a785938bfa3ef9db

application/bootstrap/app.php に追記してみてください。

takuro hishikawa様
ありがとうございます。
早速テストしてみましたが、結果は変わりませんでした。
https:で表示させたページのソースを見ると
var CCM_APPLICATION_URL = "http://mydomain.com";
となっており、やはり反映されていないようです。

※一応付け加えておきますと、以前書いた通り、
_SERVER["HTTPS"] = on
はデフォルト状態でサーバーから返されています。

念のため、コードを追加させたときの/ccm/request_testデータを貼付けておきます。
※今回もドメインとIPは一部伏せてあります。
※219.98.***.***は全て同一のIPアドレスです。

Application environment:
production
Client IP:
219.98.***.***
Host:
mydomain.com
Port:
80
Scheme:
http
Secure:
false
Canonical URL:
http://mydomain.com/
Get all headers:
array(8) {
["Host"]=>
string(11) "mydomain.com"
["Accept"]=>
string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
["Upgrade-Insecure-Requests"]=>
string(1) "1"
["User-Agent"]=>
string(120) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
["Accept-Encoding"]=>
string(23) "gzip, deflate, sdch, br"
["Accept-Language"]=>
string(23) "ja,en-US;q=0.8,en;q=0.6"
["X-Sakura-Forwarded-For"]=>
string(14) "219.98.***.***"
["Connection"]=>
string(5) "close"
}
よろしくお願いいたします。

すいません、一部記述が間違ってました。修正しましたので、もう一度お試しください。
http://gist.github.com/hissy/d9063ade6cfb6471a785938bfa3ef9db

takuro hishikawa様

ありがとうございます、
app.phpの追記はこれで良いのでしょうか？
添付ファイルを拡張子を変えてつけています

変化は感じられずです。

結果はこうでています。
IPとURLは伏字にしています。

http://www.****/ccm/request_test

Application environment:
production
Client IP:
153.142.***.***
Host:
www.***
Port:
80
Scheme:
http
Secure:
false
Canonical URL:
http://www.****/
Get all headers:
array(9) {
["Host"]=>
string(17) "www.****"
["Upgrade-Insecure-Requests"]=>
string(1) "1"
["User-Agent"]=>
string(120) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36"
["Accept"]=>
string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
["Accept-Encoding"]=>
string(23) "gzip, deflate, sdch, br"
["Accept-Language"]=>
string(23) "ja,en-US;q=0.8,en;q=0.6"
["Cookie"]=>
string(75) "CONCRETE5=4a40359bc45a4e6d830d76f28d72238a; _ga=GA1.3.1533531430.1465778317"
["X-Sakura-Forwarded-For"]=>
string(15) "153.142.***.***"
["Connection"]=>
string(5) "close"
}

となっています。

宜しくお願いします。

うーん、うまくいかないですね。一度、一部コメントアウトしてみてもらえますか。強制的にHTTPS状態になると思うのですが。。

// if ($request->headers->has('HTTP_X_SAKURA_FORWARDED_FOR')) {
$request->server->set('HTTPS', 'on');
// }

hishikawa様ありがとうございます。
試してみました。

ページが開けません
多くのリダイレクトが発生しています。

という画面になりました。

昨日とポートが変わってました。

Application environment:
production
Client IP:
153.142.xxx.xxx
Host:
http://www.xxxxxx
Port:
443
Scheme:
https
Secure:
true
Canonical URL:
http://www.xxxxxx/
Get all headers:
array(9) {
["Host"]=>
string(17) "www.xxxxxx"
["Upgrade-Insecure-Requests"]=>
string(1) "1"
["User-Agent"]=>
string(120) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36"
["Accept"]=>
string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
["Accept-Encoding"]=>
string(23) "gzip, deflate, sdch, br"
["Accept-Language"]=>
string(23) "ja,en-US;q=0.8,en;q=0.6"
["Cookie"]=>
string(210) "ConcreteSitemap-select=; ConcreteSitemap-expand=1; ConcreteSitemap-active=202; ConcreteSitemap-focus=202; dashboardPanelStatus=closed; CONCRETE5=d1e0a88a0dd7a55d11d5eed9c7332947; _ga=GA1.3.1533531430.1465778317"
["X-Sakura-Forwarded-For"]=>
string(15) "153.142.xxx.xxx"
["Connection"]=>
string(5) "close"
}

ポートとスキーマはhttpsに変更できたので、あと少しという感じですが、うまくいきませんね。

初めまして。
現在、作成中のConcrete5サイトが同じような条件下でしたので、
こちらのフォーラムをずっと参考にさせていただいてましたが、
同じ問題でお困りの方が多いようなので、当方が試した結果を共有致します。

さくらのレンタルサーバースタンダード
ラピッドSSL(SNI SSL)
Concrete5はCore Version - 5.7.5.8で、
常時SSLをhttp://xxx.com/ で行うようにしています。
（コモンネームは xxx.com ）

さくらインターネット側のコントロールパネルでの設定は
www無しとwwwありをそれぞれ別々のドメインとして設定し、
SNI SSLはwww無しのhttp://xxx.com/ のみに証明書をインストール、
・wwwを付与せずマルチドメインとして使用する（上級者向け）
を選択してます。
またwwwありの方は物理的に別のディレクトリに設定して、mod_rewriteでwww無しhttpsにアクセスするようにしてます。

.htaccessの設定は特に変更せず、
Concrete5側は SSL Redirect Configuration のアドオンを使用し、設定で *(ワイルドカート)で全てのアクセスをSSL Redirectする設定にしてます。

また、 application/boostrap/app.php の先頭に、

$request = Request::getInstance();
if ($request->headers->has('HTTP_X_SAKURA_FORWARDED_FOR')) {
$request->server->set('HTTPS', 'on');
$request->env->set('HTTPS', 'on');
$request->server->set('HTTP_HOST', 'xxx.com');
$request->env->set('HTTP_HOST', 'xxx.com');
$request->server->set('SERVER_NAME', 'xxx.com');
$request->env->set('SERVER_NAME', 'xxx.com');
}

を追加して強制的なSSLアクセスと、
曖昧な解釈になってしまうらしい、さくらレンタルサーバーのHOSTなどを、www無しのURIに強制固定するようにしています。

さて、このような設定の状態での挙動ですが、

http://xxx.com →http://xxx.com にリダイレクト
http://www.xxx.com →http://xxx.com にリダイレクト
してくれます。
トップページは問題なく表示され、cssやjsなど全てのアクセスがSSL化できています。

問題は「プリティーURL」の設定を行った時で、
http://xxx.com/contact などには無限ループに入ってしまい表示できません。
ですがプリティーURLの設定を解除すると、
http://xxx.com/index.php/contact となって問題なくSSLで表示可能でした。
（全て確認できてませんが）管理画面(index.php/dashboard)も問題なく機能しているようです。

出来ればプリティーURL設定を行った状態で各ページがSSLで動いてくれれば、
理想的なさくらレンタルサーバーでの常時SSL化が完成するのですが。。

長文失礼致しました。
どなたかの参考になれば幸いです。

chakn様
ありがとうございます。

さくらインターネット側のコントロールパネルでの設定は
www無しとwwwありをそれぞれ別々のドメインとして設定し、
SNI SSLはwww無しのhttp://xxx.com/ のみに証明書をインストール、
・wwwを付与せずマルチドメインとして使用する（上級者向け）

この部分が、事情があり対応できないので
試すことはできませんでした。
この部分が重要な要素ぽいのでしょうか？


プリティURL設定を外したりしても
うちの環境ではうまくいきませんでした。
現状でもメールフォームやログイン画面のように文字を入力する画面と
トップページ以外は、https:とて入力すれば鍵付きで表示されるます。

本件、皆様のアドバイスと確認用プログラムと報告を基になんとか解決出来たっぽいのでご報告いたします。
ど〜〜しても解決したかったので新たにドメイン＋ラピッドSSLを購入して下記状態で検証してみました。

・concrete5 5.7.5.9（Elementalをインストール）
・さくらスタンダードプラン（ただし無料お試し期間）
・ラピッドSSL
・.htaccessは「使わないドメイン」の方だけ設定します。
・使いたいドメインを「https://domain.com」として説明

1）afujiwara様と同様に、コントロールパネルにて
　　www無しとwww有りを別々のドメインとして設定します。
　　　→wwwを付与せずマルチドメインとして使用する（上級者向け）
　　　　の設定を使います。
　　フォルダもそれぞれ別の物を指定します。
　　両方にSNI SSLを設定します。
　　　→最初に片方のドメインで登録し、その後、
　　　　秘密鍵のバックアップと会員メニュー＞契約情報から
　　　　サーバー証明書をダウンロードして2個目に登録可能です。

2）ssl_redirect_confをインストールします。
　　URLルール（パス）に「*」だけ設定します。

3）プリティーURLを設定します。
　プリティーURLは「URLから index.php を除く」にチェックを入れます。

4）application/bootstrap/app.php に下記を追記します。
$request = Request::getInstance();
if ($request->headers->has('X-Sakura-Forwarded-For')) {
$request->server->set('HTTPS', 'on');
}

　※takuro hishikawa様、afujiwara様のデータとは異なり、
　「HTTP_X_SAKURA_FORWARDED_FOR」の部分を「X-Sakura-Forwarded-For」
　に変更しています。
　※host名が曖昧になってしまうのは上記1）の箇所で
　「マルチドメインとして使用する（推奨）」を設定した場合のみ
　のようなので、他は省略しても大丈夫でした。

5）下記内容で application/config/にconcrete.phpというファイルを作成します。
<?php
return array(
'seo' => array(
'canonical_url' => 'https://domain.com/',
'canonical_ssl_url' => 'https://domain.com/',
),
);

参考：https://gist.github.com/katzueno/38eeecb606c7ea5661953cd6368ef972

6）最後に使わないドメイン（www.domain.com）のフォルダに.htaccessファイルを作成し、301リダイレクトを設定します。

以上となります。
これで下記全てプリティーURLを有効にしてリダイレクト可能でした。
http://domain.com/ → 'https://domain.com/'
http://www.domain.com/ → 'https://domain.com/'
http://www.domain.com/ → 'https://domain.com/'

今回、最大のヒントとなったのはafujiwara様の「問題は「プリティーURL」の設定を行った時」という一言でした。それを基に素の状態からデータを確認し、プリティーURLの有無でポートとスキーマだけでなく、Canonical URLまでデータが変更されている事が判り、それが無限ループの原因特定に繋がりました。

参考：インストール直後のhttps接続でccm/request_testの情報
　　　プリティURL無効
　　　　Host: domain.com
　　　　Port: 443
　　　　Scheme: https
　　　　Secure: true
　　　　Canonical URL: 'https://domain.com/'

　　　プリティURL有効
　　　　Host: domain.com
　　　　Port: 80
　　　　Scheme: http
　　　　Secure: false
　　　　Canonical URL: 'http://domain.com/'
　　　
takuro hishikawa様、afujiwara様をはじめ、皆様沢山のヒントとアドバイスありがとうございました。

Katz Ueno様にUstラジオで相談し、5）の部分を変更いたしました。
Katz Ueno様アドバイスありがとうございました。

また、基本的な設定は同じですが、初心者向けに少しだけ詳細な設定方法を追記したものをqiitaにアップしました。
http://qiita.com/aniya/items/664491b523fe6c717b13
ご参考になれば幸いです。

最近、さくらインターネットのスタンダードで無料 SSL の設定をしましたが、特に何もしなくて有効になりました。
https へのリダイレクトの方法も SSL の設定画面に『WordPress以外で作成されたサイトをご利用のお客さま』というリンクあり、そこに書かれている記述で問題なくリダイレクトもできました。

さくらインターネットさんで何か対応してくれたのかも知れません。
ただ、問題がなかったのは、わたしの環境だけかも知れませんので、SSL に切り替える場合はご注意ください。

nipperさん、突然ですが伺いたいことがあります。

こちらの書き込みを拝見して、さくらスタンダードでのSSLを試してみました。
concrete5のファイルが入っているフォルダ内にある、htaccessファイルにコードを追加して試してみました。
追加したコードは次の通りです。

SetEnvIf REDIRECT_HTTPS (.*) HTTPS=$1
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{ENV:HTTPS} !on
RewriteRule .*http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

設定後、リダイレクト（httpからhttps）のチェックをしてみたのですがそこで問題が。
トップページはうまく転送できたのですが、その他のページはどれも転送できませんでした。
concrete5で行う場合、特別な設定などあるのでしょうか。

よろしくお願いします。

JINTANさま

htaccess に、concrete5用の記述はありませんでしたか？
concrete5用の記述に上記のコードを追加したということでしょうか？

どのような構成になっているのかわからないので何ともいえないのですが、concrete5のファイルが入っているフォルダの htaccess ではなく、ルートの htaccess に記述しても同じでしょうか？

以前は、このスレッドにあるように設定が大変だったのですが、おそらく今年に入ってからは特に concrete5 用の設定を記述しなくても大丈夫だったと思います。
テーマのライブデモサイトは、問題なく動作していますし...

あと、www 有り無しの設定も関係している可能性もあるかも。

よろしくお願いします。

nipperさま

返信ありがとうございます。
もともとあったconcrete5のhtaccess記述に続けてコピーしました。
また、ルートにあるhtaccessに記述しても同じ動作でした。

トップページは転送できているのでとりあえずはと言ったところですが、googleに2重コンテンツと思われてしまわないかと心配で。

wwwの有無も同じリダイレクトの設定で関係してそうですし、今まで気にしていませんでしたがちょっと調べてみたいと思います。

ありがとうございました。

いろいろ試していてわかったんですが、concrete5で作成されるページのURLの最後に”/"がつかないのがいけないようです。
通常concrete5で作成されたページだと、URLの最後にスラッシュがつかないようですが、試しにスラッシュを追加したURLで試したところhttpsに転送されました。

スラッシュの有無に対する対策はあるのでしょうか？

こちらをご覧ください。

http://concrete5-japan.org/community/forums/beginner/post-15379/

nipperさま

お忙しいところ申し訳ございません。
再度スラッシュをつけて試しましたが転送できませんでした。

慌てて作業をしていて、どこかに間違いがあったのかもしれません。
落ち着いて再度試してみます。

申し訳ありませんでした。

先日nipperさんからサンプルサイトはうまくいっていると教えていただいたので、自分のサイトと何が違うのか比べてみました。

パッと見で違う点と言えば、日本語URLを使っているという点でした。
そういえばドメイン変更でリダイレクトした時にも日本語URLで苦労したので、これが原因なのかもと。

もしご存じの方がいらっしゃいましたら教えていただけないでしょうか。
よろしくお願いいたします。

やっと解決しました。

もしかしたら.htaccessを知っている方なら常識なのかもしれませんが、プリティーURLの構文の前にリダイレクトの構文を入れたら問題なくリダイレクト出来ました。

お騒がせしまして申し訳ありませんでした。