HSTSはHTTPSで正常に表示できることを確認してから有効にする

HSTSを設定する前に、サイトのHTTPS版がすべての必要なURLで正常に表示できることを確認してください。HSTSは、ブラウザーに対して、そのサイトへはHTTPSで接続するように知らせる仕組みです。一度受け取ったブラウザーは、HTTPのURLを開こうとしてもHTTPSで接続します。

HTTPからHTTPSへの転送はサーバー側の設定です。HSTSは利用者のブラウザーが覚える方針です。役割が違うため、HTTPS移行が途中のサイトでHSTSだけを先に有効にしても、移行の確認にはなりません。

HSTSはHTTPSを使える状態にする設定ではない

RFC 6797は、HSTSをStrict-Transport-SecurityというHTTP応答headerで伝える方式として定めています。対応するブラウザーは、その方針を受け取ったhostへのHTTP接続をHTTPSへ切り替えます。安全な接続で問題が起きたときも、利用者が警告を無視して進むことを前提にしません。

ここで必要なのは、HTTPSへ切り替えることではなく、HTTPSで困らずに使える状態を先に作ることです。証明書の期限が切れている、HTTPSで表示できないURLがある、画像やスクリプトをHTTPで読んでいる、といった状態で強制を始めると、利用者が開けないページを増やします。

HSTSは、検索順位を上げるための設定ではありません。HTTPSで提供すると決めたsiteが、利用者の接続をHTTPへ戻さないための方針です。設定名だけを増やすより、HTTPとHTTPSのどちらを正本にするかを先に決めます。

サブドメインはまとめて強制しない

HSTSには、subdomainにも方針を適用するincludeSubDomainsという指定があります。これを付けると、たとえばwww.example.jpだけでなく、その配下のhostにも影響します。

この指定は、subdomainをすべてHTTPSで提供できると確認できた場合に使います。メール、画像配信、検証用の環境など、別の担当が管理しているhostまで同じ条件で使えるとは限りません。使っていないsubdomainでも、将来必要になったときにHTTPでしか動かない状態では困ります。

制作やサーバー管理を外部へ頼む場合は、HSTSを入れる作業と、対象hostを決める仕事を分けてください。作業者がheaderを設定しても、どのsubdomainを公開し、誰が証明書を更新するかは、siteを持つ側が決めます。

有効期間は戻せる前提で試す

HSTSは、ブラウザーが方針を保存する期間をmax-ageで伝えます。長い期間を指定すると、その間は利用者のブラウザーがHTTPS接続を続けます。設定を間違えたときに、サーバーの設定だけを戻しても、すでに方針を受け取った利用者にはすぐ反映されません。

最初から長い期間に決め打ちせず、まず短い期間で主要URL、HTTPからの転送、証明書、ページ内の読込先を確認します。問題がないことを確かめてから、運用できる期間へ伸ばします。ここでいう確認は、設定画面に保存したことではなく、実際にブラウザーで開いた結果です。

ただし、HSTSは最初にHTTPでアクセスした利用者へ方針を伝える仕組みです。HSTSだけで、偽サイトへの誘導や利用者の端末に入った不正なプログラムまで防げるわけではありません。HTTPS移行、管理画面の権限管理、更新を別々の仕事として続けます。

最初の一手は、公開しているhostを一覧にして、HTTPSで使うものと使わないものを分けることです。HSTSを有効にするのは、その一覧と証明書の担当を確認した後にします。