サイト全体の常時SSL化とは、すなわちAlways on SSL(AOSSL)化することをいいます。実際にはSSLではなく、TLSをつかうのが主流なので、本来なら常時HTTPS化のほうが現実に即した言い方ですが、常時SSLが一般に使われているので、そちらを使います。すなわち、全てのアドレスがhttp://〜から、https://〜に変わることを意味しています。

著名なサイトが、続々と常時SSL化に移行しています。ヤフージャパンが、2016年4月から1年かけて順次、各サービスを常時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日毎に自動更新されます。

Xサーバー:無料独自SSL

その他、CoreSSLやSecureCoreなど、低価格なSSLが使えますので、使い勝手で比較してもよいでしょう。

その外、Movable TypeのASPサービスである、movabletype.netでも、チェックボックスにチェックをいれるだけで常時SSL化できます。すごく簡単です。

ソーシャルカウンターがリセットされるのは何か対策ないの?

 ・常時https/SSL化してもFacebook記事の「いいね!」数を引き継ぐ方法(正攻法編)

上記記事によると、Facebook公式ページに2つ方法が紹介されており、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化していって焦る気持ちもわかるのですが、所詮1%の検索アルゴリズム。焦る気持ちをおさえて、しっかり計画を立てて実施しましょう。

(担当:小山智久)