kigoulab サイト全体の常時SSL化とは、すなわちAlways on SSL(AOSSL)化することをいいます。実際にはSSLではなく、TLSをつかうのが主流なので、本来なら常時HTTPS化のほうが現実に即した言い方ですが、常時SSLが一般に使われているので、そちらを使います。すなわち、全てのアドレスがhttp://〜から、https://〜に変わることを意味しています。
著名なサイトが、続々と常時SSL化に移行しています。ヤフージャパンが、2016年４月から１年かけて順次、各サービスを常時SSL化させるほか、GoogleやFacebook、TwitterのようなSNSはもちろん、任天堂や小学館のような一般企業まで対応はひろがっています。これはなぜなのでしょう。
Googleからのアナウンス
2014年8月、Googleは、HTTPSをランキングシグナルに使用するとともに、サイト全体をHTTPS化することを推奨する文章を、ウェブマスター向け公式ブログで発表しました。すなわちサイト全体がHTTPSになっているサイトのほうがSEO的に今後有利になるということです。
本来、フォームメールやクレジットカードを入力する画面で使われてきたHTTPSを、サイト全体に利用するのはどのような意味（メリット）があるのでしょう。
常時SSLのメリット
常時SSLには以下のようなメリットがあると言われています。
HTTPSとHTTPの通信が混在しない
HTTPSとHTTPのページが混在している場合、そのページ間をまたいでいるときに、通信内容が混在することがあり、セキュリティ的に不安定になります。
SEOにほんの少し有利
GoogleのSEOへのランキング向上、ただし、速度向上と同様、影響範囲は1%未満とのことです。微妙ですね。
サイトのセキュリティ強化
なりすまし防止、改ざん防止、マルウエア対策、盗聴対策、Wi-Fiからの安全な接続などが期待されます。
サイトの安全性をアピールできる。
鍵マークや、EV SSLの緑のバーなど、一目で安全なサイトであることを証明できます。
SSLの有無で、サイト構成を考える必要がなくなる
フォルダーの配置や、リンクの記述など、HTTP/HTTPS用に書き分けたりしなくて済みます。
SEOヘの影響は、さほど大きくないのは残念ですね。常時HTTPS化してない人には一安心ですが。
常時SSLのデメリット
メリットあるところに、かならずデメリットもあります。こちらも押さえておきましょう。
導入費用がかかる。
証明書の費用、設定代行費用、サイト内のリンクを書き換え等の改修費用がかかります。
証明書に至っては、毎年かかる費用になります。ただし、無料の証明書が存在します。これについては後述します。
HTTPSに非対応なツールが使えなくなる。
Amazonアフリエイト、A8ネット、ニコニコ動画などがまだHTTPSに対応していません。恐らく順次対応していくと思われますが、アフリエイトサイトなどは、時期尚早のようですね。
ソーシャルカウンターがリセットされる。
Facebookの「いいね数」などのカウンターがリセットされます。これについては、FacebookクローラーだけHTTPでアクセスさせるなどの裏技で対応可能とのことですが、具体策については情報が錯綜しています。その他のソーシャルメディアについては情報がありません。
Google Search Consoleに再登録が必要
HTTPとHTTPSは別サイトになりますので、再度登録が必要です。
使っているサーバーが、常時SSL化に対応しづらい場合がある
SSLを使うときは専用ディレクトリーでないと使えない、.htaccessが使えないなど、そのサーバー自体が常時HTTPS化に向いてない場合があります。
個人的感想としては、企業サイトは移行しやすいものの、ソーシャル連携が多いブログ・オウンドメディアなどは、最初から対応してないと、途中からの移行はかなり難しいと思われます。
（当オウンドメディアも、ソーシャルカウンターのリセット問題があって、移行の計画はあるのですが、実行に移せていません。）
無料証明書を利用して常時SSL化を実現する。
従来、証明書は、3万円台〜20万円台（EV証明書）と、価格も高価で、毎年更新する必要がありました。最近は数千円台のものもでてきましたが、証明のランクによって、ドメイン証明、企業認証、EV認証とあり、それぞれ段階的に認証範囲がことなり、それによって料金がことなっています。Googleのアナウンスのあと、もっと安価な証明書が求められるようになりました。
Googleのアナウンスがあった、3ヶ月後、電子フロンティア財団が発表した、SSL/TLSの採用促進計画で、Let’s Encryptプロジェクトが立ち上げられました。運営は、MozillaやCisco Systems、ミシガン大学などが中心に、協同で設立した非営利団体のISRG「Internet Security Research Group 」が運営しています。これらは、「無料・自動・安全・透明性・オープン・協同」を原則として、より経済的に、スムーズに、かつ効果的に誰もが手軽にSSL/TLS証明書を導入できるようにしようとしています。
特徴として、Let’s Encryptの証明書の期限は、90日間です。期限がきたら、再度延長の手続きが必要です。これは、秘密鍵や誤発行された証明書があった場合にも、短い期間で無効化されるという点、2つ目はLet’s Encryptをその都度更新するのが面倒になったユーザが、SSL証明書の更新を自動化するのを促進できるという点で、そのような期限になっています。
無料証明書の認証範囲
企業認証やEV認証は、Let’s Encryptにはありません。あくまでもSSL/TSLの普及を目的としたプロジェクトなので、ドメイン認証までしか行っていません。より高いレベルの認証が必要な場合は、市販の認証を取得することを検討しましょう。
どこで手にはいるの、無料証明書
サーバーを自分で運営している人は、Certbot クライアントをインストールして、直接証明書を取得して運用することが出来ると思いますが、エンジニア向けの専門的な情報になりますので、その方法は、他のサイトにお任せして、ここでは、共用サーバーとして利用できるところをご紹介したいと思います。
プロパイダ–のXサーバーでは、Let’s Encryptが面倒な手続きもなく利用可能で、更新も90日毎に自動更新されます。
その他、CoreSSLやSecureCoreなど、低価格なSSLが使えますので、使い勝手で比較してもよいでしょう。
その外、Movable TypeのASPサービスである、movabletype.netでも、チェックボックスにチェックをいれるだけで常時SSL化できます。すごく簡単です。
ソーシャルカウンターがリセットされるのは何か対策ないの？
・常時https/SSL化してもFacebook記事の「いいね!」数を引き継ぐ方法（正攻法編）
上記記事によると、Facebook公式ページに２つ方法が紹介されており、1つめが推奨とのこと、その方法とは、
・og:urlでold-url側を指し、かつFacebookのクローラーがold-urlページを参照できるよう301リダイレクトの対象からはずす。
とのこと。ようするに、古いコンテンツに対しては、og:urlでHTTPのものをFacebookのクローラーに伝え、HTTPS以降のコンテンツには、HTTPSのURLを伝えるということです。その為に、Movable Typeの場合の表示出し分け方法などが紹介されています。
Facebookクローラーを除いて301リダイレクトする記述方法は以下の通りです。記事の著者の方におしえていただきました。ありがとうございました。
以下、標準的な設定のLinux Apache を想定したときに、 .htaccessに記述する方法です。
# UAがfacebooketxternalhit を含まない
# UAがFacebotを含まない
# httpsではない
# ならばquerystring含めてhttpsに301リダイレクトして処理終了
RewriteCond %{HTTP_USER_AGENT} !facebookexternalhit
RewriteCond %{HTTP_USER_AGENT} !Facebot
RewriteCond %{HTTPS} !on
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]
常時SSLはまったなし、でも焦る必要もなし。準備万端にすすめればいい
以上、時代が常時SSLに動くなかで、新しく作成するサイトは、最初から常時SSLで作成するのが理想ですが、現状動いているサイトを常時HTTPSに変える場合は、メリットとデメリット両面があります。特にソーシャルカウンターの話は結構、やっかいです。Facebookの話を中心に話しましたが、Twitterは？はてブは？と、考えると結構頭痛くなります。いっそカウンター0からやり直しですかね。それも寂しいですね。(そもそもTwitterのカウンターは外部API経由でないと取得できない）
時代は動いてるので、周りがどんどん、常時HTTPS化していって焦る気持ちもわかるのですが、所詮１％の検索アルゴリズム。焦る気持ちをおさえて、しっかり計画を立てて実施しましょう。
（担当：小山智久）