Googleが2014年に、「HTTPS をランキング シグナルに使用します」と発表し、常時SSL化が推奨されるようになりました。サイト運営者側からすると常時SSLが検索順位に優位になるという利点もありますが、ユーザーにとってもアクセスしたサイトがセキュアであることに越したことはありません。
昔はSSL(独自SSL)導入となると結構な費用負担になったのですが、現在はSNI(Server Name Indication)を利用したSSLを導入することで、かなりランニングコストを抑えることができ、個人サイトでも導入できる価格になりました。
現在SNI SSLを利用できるレンタルサーバー(共用サーバー)は多くありませんが、大手では「さくら」で利用でき、2015年9月16日から「エックスサーバー」でも利用できるようになりました。
導入費用はエックスサーバーを例にすると、初期費用は無料で、CoreSSLが年間1,000円、ラピッドSSLが年間1,500円という価格です。サイトシールが使えるSecureCoreとジオトラストは少々高めです。
CoreSSL | ラピッドSSL | SecureCore | ジオトラスト | |
1年 | 1,000円 | 1,500円 | 9,000円 | 14,000円 |
2年 | 1,800円 | 2,700円 | 17,000円 | 26,000円 |
3年 | 2,500円 | 3,200円 | 24,000円 | 36,000円 |
SNI SSLはSSL専用のIPアドレスが不要なため、その分安く利用できるという感じです。デメリットとしては、SNIに対応していないウェブブラウザがあるということが挙げられます。
特に気になるのが、Internet Explorer 7 以降(Windows XP は非対応)についてで、アクセス解析を見ると、Windows XP ユーザーは少数まだ存在しているようですが、Windows XP のサポートが2014年に終了したことを考えると、今後は減少方向なのでWindows XP は切り捨ててもいいと思います。現在の主要ブラウザはSNIに対応しているので、古いブラウザに対応していないことが導入する上での障害にはならず、年間1,000円からという低価格でSSLを導入できるメリットの方が大きいのではないでしょうか。
非SSLの既存のサイトを常時SSL化する場合は、http://からhttps://に301リダイレクトしたり、HTTPで読み込んでいるコンテンツ(画像やJavaScriptやCSSファイルなど)を警告が出ないように修正したりと、細かい作業をしなければいけませんし、せっかく集めたFacebookや、Twitterや、はてなブックマーク等のソーシャルシェア数はURLが変わるためリセットされ「0」になってしまいます。このように後からSSL化する場合、ハードルが上がります。
また、将来的にGoogle ChromeでHTTPSではないサイトに警告を発するようになるかもしれません。
Google Chrome ブラウザが、HTTPSではないサイトに対して警告を発するように将来的になるかもしれません。
引用元:https://www.suzukikenichi.com/blog/google-chrome-may-warns-against-non-http-sites-in-the-future/
また、iOS 9 から搭載された新機能に App Transport Security(ATS)というものがあり、ATSの機能が有効なWebViewアプリから、HTTP のページにアクセスができなくなるということで、この先HTTP接続しかできない場合にいろいろと問題となるケースが増えてくるかもしれません。
このような現状を考えると、低価格でSSLを導入できる今、本気で運営し長く続けていきたいサイトで、新規に作成する場合は、サイト丸ごと常時SSL化で作成するのが無難ではないかと思います。
レンタルサーバーによるかもしれませんが、エックスサーバーの場合だと、SSLの導入はエックスサーバーでSSLサーバー証明書のインストール作業をやってくれるので難しくありませんし、SSL化したからといって、サイト作りが難しくなるということはなく、「プライバシーが保護されません」という警告が出ないようHTTPのファイルを読み込まないことに気をつければ、HTTPのサイトを作っている時と同じように作れます。SSL用のディレクトリとかはなく、HTTP のサイトと同じようにpublic_htmlにファイルをアップロードすればhttps://でアクセスできます。
エックスサーバーで使えるSSLサーバー証明書
エックスサーバーで使える独自SSLは、ラピッドSSL とジオトラストとグローバルサインと CoreSSL と SecureCore の5つです。
僕がSSLサーバー証明書を取得した当時は SNI SSL がなかったのでIPアドレスベースのラピッドSSLでSSLサーバー証明書を取得したのですが、今個人サイトとして導入するなら、一番安いSNI SSL(ネームベース)の CoreSSL にしていると思います。
ラピッドSSL と CoreSSL 以外はサイトシールを使えます。(ラピッドSSLでも、↓こんな感じに、サイトシールの画像をサイトに表示することは可能です。)
エックスサーバーでSSLサーバー証明書をインストールする手順
以下は、SNI SSL(ネームベース)のSecureCore ドメイン認証SSLを取得した時の流れです。
1. SSL新規取得の申し込み
- 購入したいSSLサーバー証明書を決めたら、インフォパネルの「追加のお申し込み」をクリックし、利用規約及び個人情報の取り扱いに同意をし、SSLの新規取得の「追加のお申し込み」をクリックします。
- SSLブランドの項目で購入したいSSLサーバー証明書と契約期間を選択し、コモンネーム(SSLを利用するドメイン名もしくは、サブドメイン名)を決めます。
www.なしのドメインでサイトを運用したい場合、2Way利用(「www.」あり/なしの両方でSSL接続)ができないため、後述しますがコモンネームを、www.ありにするか、www.なしにするかは、よく考えたほうがいいと思います。 - そして、料金の支払い画面で決済を行います。
- 決済が完了すると、「【Xserver】SSL新規取得手続きのご案内」というメール届くので、このメールに書いてある「SSL新規取得手続き手順」を行います。
2. SSL新規取得手続き
- インフォパネルの「ご契約一覧」の「SSL証明書」から「取得申請」をクリックします。
- CSR情報(SSL証明書申請情報)を入力し、「SSL登録者情報入力へ進む」をクリックします。
- 登録者情報を入力します。
SSL発行手続きに必要な承認を行う方法として、承認メールとDNS認証を利用する2つの方法があります。コモンネームのドメインにおけるネームサーバーが「ns1.xserver.ne.jp~ns5.xserver.ne.jp」に向いていればDNS認証を利用できます。それ以外の場合は承認メールを受信して認証します。承認用メールアドレスとして使えるメールアドレスは限られますので、admin@コモンネームのドメイン、administrator@~、hostmaster@~、postmaster@~、webmaster@~、のいずれかのメールアドレスで受信できるようにしておきます。
また、ここで入力した個人情報はwhoisのように、WEB上に公開されるということはありません。 - 入力を完了し、「SSL新規取得申請を行う」をクリックすると、DNS認証を利用した場合はこれで作業完了です。DNS認証を利用しなかった場合は、承認用メールアドレスに、SSL発行の承認メールが届きます。メールにあるURLにアクセスして「承認します」をクリックすると作業完了です。後はエックスサーバーでSSLサーバ証明書のインストールを行ってくれます。
僕の場合は15分後くらいに「【Xserver】SSL証明書設定完了のお知らせ」というメールが届き、SSL接続できるようになりました。
エックスサーバーのマニュアルページにも独自SSLの申し込み方法が書いてあります。
http://www.xserver.ne.jp/manual/man_order_domain_ssl.php
プリロードHSTSを登録
プリロードHSTS(HTTP Strict Transport Security)を登録しておけば、対応しているブラウザなら http://でアクセスされても、https://に強制的にアクセスさせることができるので、サイト丸ごとSSL化したのであれば、登録しておいたほうがいいと思います。
登録するには、.htaccessに下記の記述をします。
Header set Strict-Transport-Security "max-age=10886400; includeSubDomains; preload"
プリロードHSTSを登録する場合、includeSubDomainsとpreloadの記述は必須となります。max-ageは秒で記入し、18週(10886400秒)以上でなければいけません。
.htaccessをサーバーにアップロードしてプリロードHSTSを登録するサイトで、ドメインを登録します。(サブドメイン単位では登録できません)
コモンネームを「www.」あり/なしのどちらにするか
「www.」ありで運営する場合は、何も考えずに「www.」ありのコモンネームにすれば「www.」あり/なしの両方からSSL接続できるので問題ないのですが、「www.」なしのコモンネームの場合、「www.」ありでSSL接続できないため、プリロードHSTSの登録確認を行うと
「このホストは、手動確認に失敗しました。あなたの証明書は、サブドメイン「www.」をカバーしていません 。多くの人が習慣で「www.」を入力しているので、プリロードHSTSはおそらくあなたのサイトに問題を引き起こすことになるでしょう。」
という警告になってしまいます。英語圏に多い習慣だと思うのでそこまで気にする必要はないのかもしれませんが、プリロードHSTSを登録している場合、https://tanacio.com でアクセスすると、https://tanacio.com に強制アクセスするので、右上の画像のように「この接続ではプライバシーが保護されません」(Google Chromeの場合)となりページを表示できません。
「www.」なしのコモンネームでSSLを取得している場合、https://www.○○○ へのアクセス自体ができず、https://www.○○○ から https://○○○ へのMETAタグによる転送や、.htaccessファイルでのリダイレクトもできないので、www.○○○とURLを直接入力した場合、ページを表示することはできません。
ですので、「www.」なしのコモンネームのこのサイトでは、今のところプリロードHSTSの登録は行わず、下記のように.htaccessに記述してHSTSを設定しています。
Header set Strict-Transport-Security "max-age=10886400;"
このサイトは今のところURLを直接入力されるようなサイトではないので、プリロードHSTSを登録しても大きな問題にはならないのですが気持ちいいものではありません。僕の場合は、フィーチャーフォンや古いブラウザやごく一部のスマートフォンからアクセスができることよりも、プリロードHSTSを優先させたい気持ちの方が強いので、「www.」なしのドメインで運営するつもりでも、コモンネームは基本的に「www.」あり/なしの両方からSSL接続できる「www.」ありにしておけばよかったなと少し後悔しています。 「www.」なしで運営する場合で『一部を除くほとんどの携帯電話(フィーチャーフォン)やWebブラウザの旧バージョン、 ごく一部のスマートフォン』からもSSL通信ができるようにしたい場合は、「www.」なしのコモンネームにした方がいいと思います。それ以前に幅広い環境でSSLに対応させたいのであれば、SNI SSL(ネームベース) のSSL証明書ではなく、IPアドレスベースのSSL証明書を使うという選択肢をまず考えたほうがいいかもしれません。
「www.」あり/なしの両方からSSL接続ができる「2Way利用」については、下記エックスサーバーのページの『SSL証明書の「2Way利用」について』に詳しく書いてあります。
http://www.xserver.ne.jp/manual/man_order_domain_ssl.php#page03
余談になりますが、エックスサーバーがSNI SSLの導入を公開した当初はCoreSSL と SecureCore の場合はコモンネームを「www.」あり/なしのどちらにしても「www.」あり/なし両方のURLでSSL通信が可能ということだったので、これでコモンネームに迷うことがなくなると喜んだのですが、今は「www.」ありの場合のみ「2Way利用」可能と、元に戻ってしまいました。残念です。
コメント