凡人の感想・ネタバレ＞その他＞バリュードメインサーバーで無料SSLを利用してサイトをSSL化する方法
執筆日 2018/3/25
スポンサーリンク
よく知られていることだが、SSL化というものにはリスクも付きまとう。自分もまさにまんまとそのリスクに引っかかりアクセス減少してしまったので、まずはSSL化したらアクセスが2割減少した話を見てもらいたい。それを見てなおSSL化したいと思うのならば、このページに戻ってきて参考にしてほしい。
まずバリュードメインが管理するサーバーでSSL化にあたって前提。
2018年3月現在、バリュードメインが管理するサーバーは「xrea」「core」「value」があるが、ここではcoreサーバーの、それも新コンパネでやった手順を書き記す。
ただし、xreaサーバーでもcoreと同じインターフェイスのコンパネなので、そのまま通用する。valueサーバーだけは新コンパネが存在しないが、そちらでも手順はほとんど同じ。「ドメイン設定」をしてから「サイト設定」を行う。
自分の場合、新コンパネに触ったのは今回無料SSLを利用する時はじめてだった。なので備忘録として以下のような点、書き記しておく。
「サイト設定」では「無料SSL」の項目にチェックを入れればこれだけで「https」でのアクセスが可能になる。それも、設定してから1分程度でhttpsでアクセス可能になる。ちなみに無料でなく有料で購入した独自SSLでも反映は同じく早い。
なお、valuedomainのこのサービスはLet's Encryptというアメリカの企業の代行で、本来なら3ヵ月ごとにSSL証明書の更新が必要だが、更新はユーザーが何かをする必要はなく、自動的に行ってくれる。バリュードメインに問い合わせたところ期限が切れる前にやってくれるとのことだが、具体的にどういうタイミングかはLet's Encrypt次第なので不明との返答ももらった。
ここで注意点。
一旦「無料SSL」にしてから「しない」に設定するとすぐにSSLは無効化されるが、それからまた「無料SSL」に設定すると、数時間の間はhttpsで接続できなくなる。(2018/3/25現在。)
つまり、「無料SSL」→「しない」→「無料SSL」と設定した場合は数時間のラグが発生するということ。これがどういう理由で発生するのかはわからないが、とにかく、最初に設定した場合は設定から1分程度でSSLは有効になるのだが、一旦「しない」にしてSSLを無効化させてから再び無料SSLを有効にした場合は次にhttpsで接続するためには時間を置く必要がある、という点を覚悟しておこう。特にリダイレクト設定してからこの辺をいじると、多くの訪問者が数時間サイトにアクセスできなくなることになるため、ここは重々注意だ。
SSL化する場合、サイトに記載しているコードで「http」のものがあればそれを全て「https」にする必要がある。これは例えばhead内に書かれたものだとか、広告のコードとかが該当するが、doctypeや他のhttpサイトへのリンクなどは修正する必要はない。サイト内の画像読み込みを相対パスでなくhttpから始まる絶対パスで記述してしまっている場合などは厄介。自分の場合はdreamweaverを使ってサイト作成しているので、「http:」で検索して問題個所を拾い、まとめて修正したのでさほどの手間はかからなかった。
広告で最も多くのサイトが利用しているであろうグーグルアドセンスコードの場合、「script async src="//pagead2.googlesyndication.com/～」のようになっていれば問題ないが、古いタイプのコードで「script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js"」のようになっていると真っ白で表示されなくなってしまうため、新しく広告を作成する、あるいは新たにソースを変える必要がある。「http://」を消して「//」にすればいい。
参考→SSL 対応の AdSense 用広告コード
ブラウザでchromeを使っている場合、ページ中に不適切な「http」要素があるとURL欄の右端に警告が表示されて、そこをクリックして当該要素ブロックを解除するという選択をすると左端の鍵が消失して警告状態になってしまう。しっかり全てのページでこれを解決してから次のリダイレクト作業へと移ろう。
SSLを有効にして「https」での接続が可能になったとしても、そちらへ誘導しなければ意味がない。
そのため次に「301リダイレクト」、それに「HSTS」というものを設定する必要がある。これが最も問題となるし、躓く可能性があるところだ。
リダイレクトはもちろん、.htaccessを作成してルートディレクトリに置き、処理が行われるようにする。HSTSも同様。
HSTSというのは「HTTP Strict Transport Security」の略称。
どういうものかというと、二回目のアクセス以降にリダイレクト処理とは別に「httpsを強制する」という仕組み。これを設定せずに301リダイレクトだけにした場合、2回目以降でもhttp→httpsへの動きは単純に301リダイレクトになり、ワンクッション置かれることになる。HSTSであればリダイレクトではなく最初からhttpsでアクセスする挙動になる、ということだろう。恐らくはこれを設定せずとも301リダイレクトだけでそう問題はない(はず)だが、グーグルはSSL化の際にはこれを推奨している。
意外とネットのどこにも掲載されていないっぽいのだが、バリュードメインのサーバーの場合、HSTSはサーバー側で最初から有効になっている、ということを肝に銘じておくこと。つまり、バリュードメインのサーバーでhttp→httpsを行う場合、HSTS設定は必要がない。逆に言うと、設定していないのにHSTS設定が有効になるので、301リダイレクト設定をして一度httpsにアクセスすると、以降はHSTSが有効になってしまうということになる。自分はバリュードメインのサポートに問い合わせをしてこれを知るまで、不必要に自分でも設定していたため、設定が二重になってしまっていた。これでもHSTSは有効になるので問題はなかったのだが、とにかく、バリュードメインのサーバー、つまりxrea、core、valueのいずれかのサーバーを利用する場合、HSTSは最初から有効になっている、ということを必ず覚えておくように。特にリダイレクト設定する場合には必ずこのことを思い出そう。
また、問い合わせした際に
Header always unset Strict-Transport-Security
Header add Strict-Transport-Security "max-age=0"
と.htaccessに記述すればサーバーに設定されているHSTSを無効化できる、ということも教えてもらった。無効化させたいならこれを書こう。
あと自分が確認した限りでは
Header always set Strict-Transport-Security "max-age=0"
でも無効化できる。
また、
Header always unset Strict-Transport-Security
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
のように記述すると、「1列目の記述でサーバーに設定されているHSTSを無効化し、2列目で改めてHSTSを設定」することになる。この記述の場合は「サブドメイン込み」で設定されている。バリュードメインで初期で設定されているものは「includeSubDomains; preload」の部分は存在しないため、このようにサーバー設定を打ち消しつつ設定しないとサブドメイン込みでのHSTS設定はできない。ただし、サブドメインごと設定することに関してのリスクは少し下に書いてあるので参照。
バリュードメインのサーバーではHSTS設定は必要はないが、ここでも一応、設定の仕方を書いておく。
.htaccessに下の2列のうちいずれかのように記述すればいい。
Header set Strict-Transport-Security "max-age=31536000"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
プリロードというのは2回目でなく1回目のアクセスから強制するというもので、こういう記述はプリロードリストに登録したい場合は必要になる。しかし、、これは必ずしもやる必要はないので、1列目が一般的になるようだ。また、includeSubDomainsを記述している場合はサブドメインも含めてHSTSが有効になる。だがサブドメインごとというのはトラブルの元になるようで、検索すると失敗談や注意喚起が出てくる。例えば以下。
・ネイキッドドメイン+HTTPSで運用するRailsアプリを5.1にアップグレードしたら、サブドメインも強制的にHTTPSになってしまった話
・SSL判定のA+を取るために安易にHSTSをONにしてはいけません。
・常時SSL＋サブドメインのワナ？ httpから勝手にhttpsになる場合
そもそもサブドメインごとにSSL設定や.htaccess設定も当然可能なので、基本的に、何もサブドメインごと巻き込んでHSTSを設定する必要はない。
ただ、プリロードリストに登録するためにはサブドメインも含める必要があるので、恐らくこれ絡みでトラブルが起きるのだろう。プリロードリストというものに登録されると二回目からではなく「初回から」httpsへと飛ばされるようになるのだが、これはSSL化にあたり何がなんでもやらなければいけないというものではない。よって、やはりシンプルに
Header set Strict-Transport-Security "max-age=31536000"
が無難。
「31536000」というのはHSTSが有効になっている秒数で、ちょうど一年間を表す。もちろん他の秒数に設定してもいいようだが、これが一般的のようだ。
これを.htaccessに記載してサイトのルートディレクトリに置く。
HSTSとリダイレクト設定を合わせるとすると、一例として
Header set Strict-Transport-Security "max-age=31536000"
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
ということになる。もちろん、example.comの部分はそれぞれのドメイン名を入れる。上で書いた通り、バリュードメインのxrea、core、valueサーバーでは一番上のHSTS設定は必要ない。
301リダイレクトに関してはドメイン名を入れず
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
でもいいらしいが、何となくドメイン名が入ってる方が安心できるので自分は上の方にした。
ここで大きな注意点。
HSTSというのは最近のブラウザだとデフォルトで有効になっているらしい。つまり、上の4行のうち1番上は記述せずとも、一旦
1回でもリダイレクトを設定してしまうと、HSTSが働いてしまう。それも31536000秒(1年間)強制される。
つまり一度httpsでアクセスしてしまうともう取り返しがつかない。httpには戻れない。httpsが見られないためあえてhttpに戻したい場合にリスクがあるということになる。
しかしこれをキャンセルする方法もある。
Header always set Strict-Transport-Security "max-age=0"
を.htaccessに書けば(もちろん31536000秒設定のものの代わりに書く)設定を上書きして消滅するのでhstsは削除できる。これを設定しておくと、一度「https」にアクセスしても「http」で直接入力すれば再びhttpに戻れる。ただしもちろん、上の一例の4行のコードのように同時にリダイレクト設定をしている場合はリダイレクトされてしまうので、リダイレクト処理も消した上でこれを設定しないとhttpにはアクセスできない。
また、ブラウザにはキャッシュが残るので.htaccessを削除したとしてもhstsの効力が残り続ける。キャッシュは消せる。上記「Header alway～」を記載すればキャッシュも働かないが、手動でキャッシュも消せる。
chromeで「chrome://net-internals/#hsts」にアクセスして一番下の「Delete domain security policies」にドメイン名を入れてDeleteボタンを押すとHSTSのキャッシュが消えてまたhttpにアクセスできる。下画像の赤丸の欄にドメインを入力してDeleteボタンを押すと消える。
もちろん、サイト利用者がこんなキャッシュ削除作業を行うはずがないので、第三者に一度httpsにアクセスされてしまった場合でhttpへ誘導したい場合、逆にhttps→httpへのリダイレクトを行うしかなくなる。
hstsの設定が残っているとhttps→httpリダイレクトとhstsによるhttp→httpsリダイレクトがループするので「リダイレクトがループしています」というエラーが出る。よって上で掲載したhsts無効化と合わせて
Header always set Strict-Transport-Security "max-age=0"
RewriteEngine on
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://example.com//$1 [R=301,L]
とするとhttps→httpリダイレクトが行える。
行う可能性があるとしたら例えば証明書の有効期限切れなどで暫定的にhttpでの表示をしたい場合など、か。
しかしhttp://composed.hateblo.jp/entry/20090615/p1によればリダイレクト処理以前に証明書エラーが出てしまうのであまり意味がないとのこと。あ、そっかあ…。
こんな緊急避難的なことをする理由といえば意味がないな…。実際、chromeでSSL化していないサイトで試したところ
この接続ではプライバシーが保護されません ～.com では、悪意のあるユーザーによって、パスワード、メッセージ、クレジット カードなどの情報が盗まれる可能性があります。
という表示が出るだけでhttpへのリダイレクトはなされなかった。つまり、SSLを無効化したからといってhttpへ誘導できるわけではないということになる。どうしたらいいのか自分にはわからない。
もちろん知識がある人にとっては簡単なところだろうが、自分のような付け焼刃にとっては、「SSL化は取り返しのつかないもの」として決死の覚悟で行った次第だ。
適切にリダイレクトされているのかどうかというのは、自分でただサイトを見ているだけではわからない。
いくつか方法があるが、自分が取った方法は主に以下4つ。
まず①。
リダイレクトチェックできるサイトにアクセスしてhttpの方でURLを記入してチェックできる。「301」のリダイレクトになっていれば設定に間違いはない。
そして②。
google consoleに登録してあるサイト(非SSL)で「Fetch as Google」からURLを入力してみるという方法。
301リダイレクトがされているとこのように表示されるはず。さらにこのページの詳細を見ると
このように「301 Moved Permanently」と表示される。こうなっていれば301リダイレクトが働いている証拠。
そして③．
ブラウザのGoogle Chromeを立ち上げ、右クリックをして「検証」を選ぶとウェブマスター用の検証ツールが立ち上がる。そして「Network」のタブを選ぶ。サイトをリロードするとそのページで読み込まれているファイルなどの全てのデータが表示されるはず。
そして、ここでURL欄であえて「http」にしてアクセスしてみる。すると
このように一番上の項目のステータスが307となる。
さらにこの307となっている項目をクリックすると
こんな感じで表示される。
301でなく307であるというのはHSTSが適切に作動しているから。HSTSを利かせている場合、307ならOK。googleの検索クローラーなどにとってはちゃんと301扱いになっており、価値は受け継がれたままhttp→httpsとなる。
④のSSL Server Testというのは、SSLを利用しているサイトの安全度を測定してくれるもの。URLを入力して数分待てば測定が終わる。最高でA＋の評価が出る。A＋を出すためにはHSTSが適切に作動している必要もある。ちなみに当サイトはちゃんとA＋が出る。SSL化していないサイトの場合は測定自体がエラーになる。
ウェブサイト運営者ならご承知の通り、ここまでの作業だけでも後は時間が経過すれば徐々にgoogleにインデックスされ、httpがhttpsに置き換わっていく。だが、google consoleに登録すればよりgoogleにサイトの構造などを適切に伝えることができる。あと、これを使うと適切にリダイレクトされているかどうかというのも調べることができる。
SSL化してURLhttpsとなった場合、google consoleには別のサイトとして登録する必要がある。
登録する際の注意点だが、サイトマップも「https」で記述して改めて登録する必要があるということ。自分はこれをうっかり忘れたりしてかなり慌ててしまった。
後はrobot.txtも設定している場合は注意。自分の場合、robot.txtでsitemapの位置も指定していたので、ここもhttpsに変更する必要があった。
サイトマップ登録に関して、自分の場合はもしかするとこれが原因でアクセス減少につながった可能性もあるのでSSL化したらアクセスが2割減少した話を参照。
凡人の感想・ネタバレ＞その他＞バリュードメインサーバーで無料SSLを利用してサイトをSSL化する方法