HSTS preload 登録の手続きと撤回リスク
目次
この記事でわかること
- HSTS preload list（プリロードリスト：ブラウザに HTTPS 強制を事前登録する仕組み）への登録に必要な 4 つの条件
- hstspreload.org での申請から実際にブラウザへ反映されるまでの流れ
- 登録は比較的すぐ進む一方、撤回（removal）には数週間以上かかり困難になる「非対称リスク」
HSTS preload とは「ブラウザに HTTPS を焼き込む」登録制度
HSTS（HTTP Strict Transport Security、RFC 6797）は、Web サーバーが「このドメインは一定期間 HTTPS でのみ接続せよ」とブラウザに宣言する仕組みです。ただし通常の HSTS は、ユーザーが一度サイトに接続して初めてブラウザが指示を記憶します。つまり「初回アクセス」の瞬間だけは HTTP 経由になりうる隙が残ります。
この隙を埋めるのが HSTS preload list です。Google が運用する hstspreload.org に登録すると、ドメインが Chrome のソースコードに直接書き込まれ、Chrome のほか Firefox・Safari・Edge など主要ブラウザに配布されます。結果として、ユーザーがそのサイトに一度もアクセスしたことがなくても、初回から HTTPS が強制されます。
HSTS そのものの動作の仕組みや、Cloudflare / Nginx / WordPress 別の設定手順はHSTS の設定方法で解説しています。本記事は preload list への登録手続きと、その後の撤回リスクに絞って扱います。
登録に必要な 4 つの条件
hstspreload.org で申請を受け付けてもらうには、申請時点でドメインが以下のすべてを満たしている必要があります（出典: hstspreload.org 公式の Submission Requirements）。
条件 1: 有効な SSL 証明書を配信している
対象ドメインが有効な SSL/TLS 証明書で HTTPS を提供していること。期限切れや自己署名の証明書では通りません。
条件 2: HTTP から HTTPS への同一ホストでのリダイレクト
80 番ポート（HTTP）でリッスンしている場合、同じホスト名のまま HTTPS へリダイレクトすること。http://example.co.jp/ が https://example.co.jp/ に転送される状態です。最初に別ドメインへ飛ばす構成は要件を満たしません。
条件 3: すべてのサブドメインで HTTPS が動いている
includeSubDomains を付ける以上、全サブドメインが HTTPS で応答できる必要があります。特に www のサブドメインに DNS レコードがある場合、そのサブドメインも HTTPS をサポートしていなければなりません。
条件 4: 指定どおりの HSTS ヘッダを返している
base ドメインの HTTPS レスポンスで、次のすべてを満たす Strict-Transport-Security ヘッダを返すこと。
- max-age が 31,536,000 秒（1 年）以上
includeSubDomainsディレクティブを含むpreloadディレクティブを含む
公式が例示しているヘッダは次のとおりです（max-age を 2 年に設定した例）。
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
この 4 条件のうち、条件 3 が最も見落としやすいポイントです。マーケ部門が独自に立てた古いサブドメインや、HTTP のみの社内向けホストが 1 つでも残っていると、includeSubDomains の影響でそこへのアクセスがブロックされます。申請前に保有サブドメインを全棚卸ししておくことが安全です。
hstspreload.org での申請フロー
条件を満たしたら、実際の登録手続きは次の流れで進みます。
- ヘッダを確認する:
hstspreload.orgの入力欄にドメインを入れると、上記 4 条件を自動チェックしてくれます。満たしていない項目は赤字で表示されます - チェックボックスに同意して送信: 4 条件をすべてクリアすると、preload list への登録を申請するボタンが有効になります。ここで「撤回が困難であること」への同意も求められます
- 承認待ち: 申請が受理されると pending 状態になります
- ブラウザへの反映: 承認された entry は Chrome のソースコードに直接書き込まれます。公式の説明では、新規 entry が Chrome の安定版（stable）へ反映されるまでに数か月かかることがあるとされています
つまり「申請ボタンを押せばその場で即有効」ではなく、ブラウザのリリースサイクルに乗って配布されるため、反映には時間がかかります。逆に言えば、申請後しばらくは preload が効いていない期間が存在します。
登録は進むが撤回は遅い、という非対称リスク
HSTS preload の最大の注意点は、登録の手続きは比較的単純なのに、撤回（removal）は遅く、扱いにくいという非対称性です。ここを理解せずに申請すると、後から大きな運用負担を抱えます。
撤回するには、まず Strict-Transport-Security ヘッダから preload ディレクティブを外します。preload を含まない有効な HSTS ヘッダを返すようにすると、そのドメインは removal フォームから撤回申請できる状態になります。HSTS を完全に無効化したい場合は max-age=0 を送る方法（knockout entry）もあります。
問題は反映までの時間です。撤回申請を出しても、それがブラウザに行き渡るまでに時間がかかります。公式の説明では、preload list からのドメイン削除が大多数の Chrome ユーザーに届くまでに 6〜12 週間かかる可能性があり、他のブラウザではさらに長くかかるとされています。削除は Chromium 開発者がソースコードを手作業で更新し、次のリリースに乗せる形で進むため、即時には反映されません。
この間、ブラウザは依然として「このドメインは必ず HTTPS で」と記憶し続けます。何らかの事情で HTTPS が提供できなくなったり、サブドメインの一部を HTTP に戻したくなったりしても、ユーザーのブラウザは頑なに HTTPS を要求し続け、エラー画面のまま操作できない状態が数週間以上続くおそれがあります。
この非対称性から導かれる実務上の結論はシンプルです。今後も恒久的に HTTPS のみで運用すると確信できるドメインだけ preload 申請する。少しでも「将来 HTTP に戻す可能性」や「HTTPS 化が済んでいないサブドメインが残るかもしれない」懸念があるなら、preload は見送り、通常の HSTS（preload ディレクティブなし）にとどめる判断が安全です。中小企業のサイト運用で起きがちな副作用や、includeSubDomains が引き起こすトラブルの具体例はHSTS の副作用と中小企業の注意点にまとめています。
申請前のチェックリスト
トラブルを避けるため、申請ボタンを押す前に次を確認してください。
- 全サブドメインの棚卸しが済んでいるか: HTTP のみのホストが 1 つも残っていないか
- 証明書の自動更新が確実に回っているか: 更新失敗で HTTPS が止まると、preload 中は復旧まで全ユーザーがアクセス不能になる
- HTTP→HTTPS リダイレクトが同一ホストで効いているか
- max-age を 1 年以上に設定済みか: いきなり 1 年で固定する前に、短い max-age での検証期間を経てから拡大したか（手順はHSTS の設定方法を参照）
- 撤回が数週間以上かかる前提を社内で共有できているか
これらが 1 つでも曖昧なら、preload 申請は急がないのが賢明です。HSTS 自体は preload なしでも十分にセキュリティ効果があります。
まずは自社の HSTS 設定状況を確認しませんか
自社サイトの HSTS ヘッダが preload の 4 条件（max-age 1 年以上・includeSubDomains・preload ディレクティブ・全サブドメイン HTTPS）を満たしているかは、ドメイン番人の無料診断で数十秒で確認できます。preload 申請の可否判断や、撤回リスクを踏まえた段階的な HSTS 導入の進め方で迷う場合は、お問い合わせフォームから状況をお知らせください。専門家が一緒に整理いたします。