HTTPからHTTPSへの301転送と、HSTSは似て見えます。違いは「HTTPで接続した後に転送するか」「ブラウザーが接続前にHTTPSを選ぶか」です。導入前に、適用範囲と取り消しにかかる時間も確認しましょう。
説明用の概念図。実測結果ではありません。
転送だけなら最初はHTTPになり得る
利用者がhttp://でアクセスしたとき、転送設定だけではHTTPリクエストを送り、その応答を受けてHTTPSへ移ります。HSTSを学習済みのブラウザーは、対象ホストへのHTTPアクセスをHTTPSへ変更して接続します。
HSTSはブラウザー側に覚えてもらう方針です。サーバーの転送設定と同じ場所で動く仕組みではありません。
ヘッダーの各要素を読む
Strict-Transport-Securityのmax-ageは、方針を保持する秒数です。includeSubDomainsを付けるとサブドメインにも影響します。HTTPS応答で受け取る必要があり、HTTP応答へ付けただけでは有効になりません。
本番用の値をそのままコピーする前に、対象のサブドメイン一覧と、すべてがHTTPSで運用できるかを確認します。
初回アクセスとpreloadを分ける
まだ方針を知らない初回アクセスの問題は、通常のヘッダーだけでは残ります。preloadは、ブラウザー側へ事前に登録される仕組みで、別の要件と手続きがあります。
文字列にpreloadを書くだけで、すべてのブラウザーへ即登録されるわけではありません。登録・削除の反映にも時間がかかるため、初期設定の一部として軽く扱わないでください。
導入前の小さな確認表
担当者、対象ホスト、サブドメイン、証明書更新経路、障害時の連絡先を一枚にします。試験範囲と保持時間を決め、段階的に確認します。
HSTSは証明書の誤りを直す機能ではなく、HTTPSを要求する方針です。証明書の更新失敗が起きても、利用者が警告を簡単に回避すればよい、という復旧計画は置けません。
一次資料
もう少し詳しく知りたい方へ
本文で扱った仕組みや運用を、図解や関連する確認項目まで掘り下げる資料です。
資料確認・執筆・図解制作にAIを使用しています。例や確認表は説明用で、実機試験の結果ではありません。