さくらインターネットの共有SSLでウェブサイトの常時SSL化を実現

ほとんどの個人ブロガーが、個人情報を扱わなければ関係ないと思っていたSSL (Secure Socket Layer)と呼ばれる暗号化通信のツール、これがすべてのウェブサイト管理者にとって必須となる時代がやってきた。

去る7月24日（米国時間）にリリースされたGoogle Chromeのバージョン68では、HTTPで始まる（通信が暗号化されていない）すべてのウェブサイトについて、ウェブアドレスの左側に「保護されていない通信」と表示されるようになったからだ。（2018年7月25日　CNET Japan－「Chrome 68」公開、HTTPサイトに「保護されていません」の警告を開始）

これが、近日中にリリース予定のバージョン70では、ラベルが赤で警告表示されるようになるという。
一般の個人ブロガーなら、あまり関係ないと言う人も多いかもしれないが、今後、SSL化されていないウェブサイトの検索順位が下がる可能性は大いにあるだろう。

そこで、私はレンタルサーバーを契約しているさくらインターネットに問い合わせると、共有SSL（無料）を導入することによって、SSL対応（暗号化通信）が可能との回答をもらったので、さっそく設定することにした。（さくらのレンタルサーバでのSSL利用－独自SSLは独自ドメインを取得しないと利用できない）
ところが、ここで大きな問題が生じた。

私のSSL化以前のURLは、http://www.carlos.sakura.ne.jp/で、このまま共有SSLを導入しても、Google Chromeでは警告表示が出てしまうと書かれている。
実際に設定してみると、ウェブアドレスの左側に警告が表示されるだけでなく、ウェブページにアクセスする前に警告が出るので、ほとんどの人が私のウェブサイトを訪問しないという事態に陥ってしまうことがわかった。

幸いにして、SSL化した後の新URLは、wwwを除いたhttps://carlos.sakura.ne.jp/になるので、リダイレクトさせれば大丈夫だった。
問題は、httpからhttpsへのリダイレクトと、wwwの有無を統一させることをダブルでやらないといけないことだった。

さくらインターネットのカスタマーサービスからは、httpからhttpsへのリダイレクトの方法は教示されていたが（暗号化(SSL)を有効としている場合、暗号化しているページへ誘導したい）、wwwを除く方法と併用するのは、ITの専門家でない私にとって至難の業だった。

いろいろインターネット情報を検索して試行錯誤すること数時間、ようやく見つけたのが、遠藤誠氏の「m630.net」というブログの記事「httpからhttpsへリダイレクトしてwwwありなしを統一する（2016年12月12日）」だった。
彼の記事を参考にして、.htaccess（ドットHTアクセス）ファイルを作成し、サーバーにアップロードすると、無事にリダイレクトされ、「保護されていない通信」という表示が消えた。

下がファイル内の記述だが、これでメインサイトの常時SSL化は完了、ブログの方は@niftyの発表待ちといったところだろうか。
ちなみに、トップページのウェブアドレスの左側のアイコンをクリックすると、「このサイトへの接続は完全には保護されていません」となるが、個別のページに行くと「この接続は保護されています」になるところもある。

何が違うのかカスタマーサービスに尋ねたら、常時SSL化されていないウェブサイトにリンクを貼ると「このサイトへの接続は完全には保護されていません」になるとのことだ。
私はこのブログがSSL化されていないので、当分の間は、そうなるだろう。

**************************************************
.htaccess（ドットHTアクセス）ファイル
（httpからhttpsへリダイレクトしてwwwありなしを統一する）

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://carlos.sakura.ne.jp/$1 [R=301,L]
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.carlos.sakura.ne.jp/)(:80)?
RewriteRule ^(.*) https://carlos.sakura.ne.jp/$1 [R=301,L]

***************************************************