公開2026.01.06更新2026.10.16 105 人が閲覧（直近 30 日）セキュリティ

「HSTS が使用されているため、現在アクセスできません」の原因と解除方法

Q: HSTS を解除するにはどうすればいいですか？

自分の端末だけなら、Chrome・Edge は chrome://net-internals/#hsts の「Delete domain security policies」でドメインを削除、Firefox は履歴から「このサイトを忘れる」、macOS の Safari は HSTS.plist を削除します。サイト側で解除するなら max-age=0 を元の max-age の期間だけ配信し続けます。

Chrome や Edge に「HSTS が使用されているため、現在アクセスできません」と出て、いつもの「詳細設定」から先へ進むリンクも出てこない。これはブラウザの故障ではありません。そのサイトの証明書に問題が起きていて、しかも HSTS（HTTP Strict Transport Security）が効いているため、警告を無視して進む操作がブラウザ側で封じられている状態です。この記事では、閲覧者としてまず確かめること、自分の端末の HSTS 記録を消す手順、消しても直らないときの判定、社内ネットワークやサイト移転のときに起きる原因、そしてサイト運営者が HSTS を設定・無効化する手順を、RFC 6797 と Chromium のソースコード、各社の公式文書で確かめた内容で整理します。

まとめ：証明書の問題をHSTSが「回避不可」にしているエラー

エラーの正体は「証明書エラー」に「HSTS による例外承認の禁止」が重なったもの。HSTS の記録を消しても、証明書の問題が残っていれば正常には開けない。
閲覧者はまず、Wi-Fi のログイン画面・端末の時計・会社のネットワークかどうかを確かめる。別の端末・別の回線でも同じように出るなら、サイト側の証明書の問題で、運営者が直すまで待つしかない。
自分の端末だけ通したいなら、Chrome・Edge は chrome://net-internals/#hsts（Edge は edge://net-internals/#hsts）の「Delete domain security policies」でドメインを削除する。
削除しても直らないなら、ブラウザ内蔵の preload リストへの登録か、親ドメインの includeSubDomains を疑う。preload は端末側では消せない。
会社でだけ出るなら FortiGate などの SSL インスペクション、サイト移転の動作確認中なら新サーバの証明書が原因。どちらも直すべきは証明書の側。
運営者が HSTS をやめるには max-age=0 を配信する。preload 登録済みなら削除申請から Chrome 利用者の大半に届くまで 6〜12 週かかる。

以下、エラーの仕組み、閲覧者の確認順序、ブラウザ別の解除手順、ネットワーク別の原因、運営者側の設定の順に説明します。

エラーが出る仕組み：証明書エラーとHSTSによる例外承認の禁止

HSTSが効いているドメインでブラウザが強制する2つの動作

HSTS は「このドメインには今後 HTTPS でしか接続しない」というルールを、サーバが Strict-Transport-Security レスポンスヘッダーでブラウザに記憶させる仕組みです。記憶が残っている間、ブラウザは次の 2 つを強制します。

HTTP でのアクセスを、ネットワークへ出す前に HTTPS へ書き換える。
TLS の証明書検証に失敗したら接続を打ち切り、ユーザーによる例外承認を認めない。

後者は RFC 6797 の 12.1 節「No User Recourse」で、ユーザーに警告を回避させてはならないと定められた動作です。つまりこのエラーは、証明書の検証失敗（期限切れ、ホスト名の不一致、自己署名、社内 CA の未導入、通信経路での証明書の差し替え）が起き、HSTS が「無視して進む」を封じた結果として表示されます。HSTS が原因なのではなく、HSTS は問題を回避できなくしているだけです。

ブラウザ別の表示文言と英語版の原文

同じ状態でも、ブラウザによって表示は違います。Chrome の文言は Chromium の文字列定義（IDS_SSL_NONOVERRIDABLE_HSTS）とその日本語訳ファイル、Firefox の文言は Mozilla の翻訳ファイルから確認しました。

ブラウザ	日本語の表示	英語版の表示
Chrome	（サイト名）では HSTS が使用されているため、現在アクセスできません。	You cannot visit (site) right now because the website uses HSTS.
Edge	Chrome と同じ趣旨（訳文は異なる）	Chromium 系の同じ画面
Firefox	接続中止: 潜在的なセキュリティ問題	Did Not Connect: Potential Security Issue

Chrome の文には続けて「通常、ネットワークエラーやネットワークへの攻撃は一時的なものです。しばらくするとページにアクセスできるようになります。」とあります。現行の Firefox は見出しだけを出し、詳細欄に「HTTP Strict Transport Security」の項目でヘッダーの有無を示します。以前の版の日本語訳では「HTTP Strict Transport Security (HSTS) と呼ばれるセキュリティポリシーが設定されており、（中略）このサイトを例外に追加することはできません。」と説明していました。例外を追加するボタンやリンクが出ないのは HSTS の典型的な症状ですが、管理ポリシーや一部の重い証明書エラー（失効など）でも出なくなるため、Chrome なら画面の文言に「HSTS」とあるかで確かめます。

「詳細設定」から進めない理由とthisisunsafeが効く条件

通常の証明書エラー画面には「詳細設定」から「（サイト名）にアクセスする（安全ではありません）」へ進むリンクがあります。HSTS が効いているドメインではこのリンクが表示されません。Chromium のソースでは、HSTS の対象で証明書エラーが起きると画面のオプションに STRICT_ENFORCEMENT が付き、リンクで進む「ソフトオーバーライド」が無効になります。

一方、エラー画面でキーボードから thisisunsafe と打つと進めることが知られています。これはエラー画面の JavaScript（interstitial_large.js）に組み込まれた「ハードオーバーライド」で、ソースを読むと HSTS の画面でも無効化されていません。止まるのは、管理者がポリシー SSLErrorOverrideAllowed（警告ページからの続行を許可）を無効にした端末だけで、例外として許すオリジンは SSLErrorOverrideAllowedForOrigins で指定されます。ソースのコメント自体が「HTTPS のエラーは深刻で無視すべきではない」と書いているとおり開発者向けの抜け道で、通したあとの通信は偽の証明書でも区別できません。業務端末や金融機関・社内システムで常用せず、原因を直す側に回ってください。

閲覧者がまず確かめる順序：Wi-Fi・時計・社内ネットワーク・サイト側

閲覧者の立場では、HSTS の記録を消す前に原因の場所を絞るほうが早く片づきます。上から順に確かめてください。

ホテル・空港・カフェの Wi-Fi か：ログインが必要な Wi-Fi は、認証前の通信をログイン画面へ横取りします。HSTS のサイトは HTTP を出さないので、横取りが証明書エラーとして現れます。http://neverssl.com のような HTTPS 化していないサイトを開くとログイン画面が出るので、認証を済ませてから開き直します。Chrome はログイン画面を検知できると、証明書エラーではなくネットワークへのログインを促す専用の画面を出すことがあります。
端末の日時が正しいか：時計が大きくずれていると、正しい証明書でも「まだ有効でない」「期限切れ」と判定されます。Chrome は時計のずれを検知すると日時設定を開くボタンを出します。仮想マシンや電池の切れた PC で起きやすい現象です。
会社・学校のネットワークでだけ出るか：同じ PC を社外の回線（スマートフォンのテザリングなど）につなぐと開けるのに、社内では出るなら、経路上の SSL インスペクション装置が証明書を差し替えている可能性が高いと言えます。後述の FortiGate の章の方法で証明書の発行者を比べ、情報システム部門に相談してください。
別の端末・別の回線でも出るか：複数の端末と回線で再現するなら、サイト側の証明書の失効や設定ミスです。同じ端末でだけ出るなら、時計に加えて、HTTPS を検査するウイルス対策ソフトや端末に入れた証明書も疑います。閲覧者が HSTS を消して開けたとしても、証明書が壊れた通信を信用することになります。運営者が直すまで待つのが正解です。

自分が管理しているサイト、自分の検証環境、社内で原因が分かっている一時的な状況に限って、次章の手順で HSTS の記録を消します。

ブラウザ別のHSTS解除手順と、削除しても消えないpreload登録の見分け方

Chrome・Edge：net-internalsによるHSTS記録の削除

サーバのヘッダーで記憶された HSTS（dynamic）は、端末側から削除できます。

アドレスバーに chrome://net-internals/#hsts（Edge は edge://net-internals/#hsts）を入力して開く。
「Query HSTS domain」の Domain 欄に対象ドメイン（例 example.com）を入れて Query を押し、状態を確認する。Chrome 154 までは見出しが「Query HSTS/PKP domain」でした。
「Delete domain security policies」の Domain 欄に同じドメインを入れて Delete を押す。
対象サイトを開き直す。

Query の結果に dynamic_sts_domain と dynamic_sts_expiry だけが出るなら、その記録は削除できます。static_sts_domain が出たら次の preload 判定へ進みます。dynamic_sts_domain に入力したものと違う親ドメイン（www.example.com を調べて example.com と出るなど）が表示されたら、親ドメインの includeSubDomains が効いているので、親ドメインの名前で削除します。削除欄の説明には「Input a domain name to delete its dynamic HSTS policy. (You cannot delete preloaded entries.)」とあり、消せるのは dynamic だけだと画面自体が明記しています。なお、サイトが HSTS ヘッダーを送り続けている限り、次に正常に接続した瞬間に再登録されます。証明書の問題が直っていなければ、削除しても同じエラーに戻ります。

Firefox・Safari：プロファイルに残るHSTS記録の削除手順

Firefox には net-internals にあたる画面がありません。履歴（Ctrl+Shift+H）で対象サイトを右クリックし「このサイトを忘れる」を実行するのが正規の手順です。プロファイル内の保存先は現行版ではバイナリ形式の SiteSecurityServiceState.bin で、旧版のようにテキストを行単位で編集することはできません。ファイルごと削除すると全サイトの HSTS 記録が消えます。

macOS の Safari は、Apple が HSTS 記録の消し方を案内していません。ネット上でよく紹介される ~/Library/Cookies/HSTS.plist の削除は、macOS 26.6.2 の手元の Mac ではこのファイルの更新日が 2020年11月のまま止まっており、現行の Safari には当てはまらない旧手順と考えられます。Safari でだけ出る場合は、Chrome や Firefox で同じサイトを開いて証明書の問題かどうかを先に確かめるのが近道です。iPhone・iPad の Safari には HSTS の記録を名指しで消す画面がありません。Apple のサポート文書が案内しているのは「設定」→「アプリ」→「Safari」→「履歴とWebサイトデータを消去」による履歴・Cookie・キャッシュの削除で、HSTS 記録が消えるとは書かれていません。試すなら全サイト分の履歴が消えることを承知のうえで行います。

削除しても直らない場合：static（preload）登録かどうかの判定

HSTS の記録には 2 種類あり、消せるかどうかが違います。

種類	登録元	端末側で削除	解除の方法
dynamic	サーバが送る STS ヘッダー	できる	net-internals で削除（再訪で再登録）
static（preload）	ブラウザ内蔵の preload リスト	できない	運営者の削除申請（6〜12週）

preload リストはブラウザ本体に同梱されているため、net-internals で Delete を押しても static の記録は消えません。登録状況は hstspreload.org にドメインを入れると確認できます。.dev や .app のように TLD ごと preload されている場合は、そのドメインには HTTP で接続できず、端末が信頼していない自己署名証明書でも接続できません。開発環境に .dev のドメインを使っていて通らなくなったなら、ブラウザ側ではなく、ドメインを .test や .localhost に変えるか、正規の証明書を入れる対処になります。

社内ネットワークでだけ出る原因：FortiGateなどのSSLディープインスペクション

「自宅や携帯回線では開けるのに、会社からだと HSTS エラーになる」という場合、まず疑うのは UTM の SSL ディープインスペクションです。FortiGate を例に取ると、HTTPS 通信を一度復号してウイルス検査や Web フィルタを掛け、再暗号化して端末へ渡します。このとき端末が受け取る証明書は、接続先の本物ではなく FortiGate が署名し直したものです。UTM の機能構成はUTMとは？統合脅威管理の機能とファイアウォールとの違い、企業の選び方を解説で整理しています。Cisco Umbrella やプロキシ型の製品、HTTPS をスキャンするウイルス対策ソフトも、仕組みは同じです。

Fortinet_CA_SSLで再署名された証明書を端末が信頼していない状態

Fortinet のFortiOS 7.6.5 Administration Guide「Deep inspection」によれば、FortiGate は再暗号化の際に Fortinet_CA_SSL、Fortinet_CA_Untrusted、または管理者がアップロードした独自 CA で署名します。Fortinet_CA_SSL はブラウザの信頼済み CA に入っていないため、端末に配布していなければ証明書エラーになります。HSTS のないサイトなら利用者は警告を承認して進めてしまい、HSTS のあるサイト（Google、主要 SaaS、金融機関など）だけが開けなくなります。「同じ社内で開けるサイトと開けないサイトがある」のはこのためです。

見分け方は証明書の発行者です。社内と社外の回線で次のコマンドを打ち、issuer が Let’s Encrypt や DigiCert などから Fortinet や自社の名前を含む CA に変わっていれば、経路で再署名されています。

openssl s_client -connect www.example.com:443 -servername www.example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Fortinet_CA_SSL を取り込んだ後も警告が残るなら、Fortinet_CA_Untrusted による再署名です。FortiGate は接続先サーバの証明書を自分で検証し、信頼できなかったときは信頼されない側の CA で署名し直して問題を端末へ伝えます。FortiOS 7.6.6 の CLI リファレンス（config firewall ssl-ssh-profile）では、HTTPS の untrusted-server-cert の既定値が allow、expired-server-cert の既定値が block です。Fortinet は Fortinet_CA_Untrusted を端末に取り込まないよう明言しており、直すべきは接続先の証明書です。

CA証明書をGPOで配布するか、ssl-exemptで除外するかの判断

全社でディープインスペクションを続けるなら、Fortinet_CA_SSL（または自社 CA）を全端末の「信頼されたルート証明機関」へ入れます。GUI の Security Profiles > SSL/SSH Inspection で deep-inspection プロファイルを開いて CA 証明書をダウンロードし、Active Directory 配下ならグループポリシー（GPO）で一括配布します。Firefox は独自の証明書ストアを持ちますが、現行のソースでは OS に追加されたルート証明書を読み込む設定 security.enterprise_roots.enabled の既定値が true です。この設定を無効にしている環境では、エンタープライズポリシーで有効にするか CA を個別に取り込みます。

もう 1 つは、問題のサイトを検査対象から外す方法です。銀行・医療系のように復号すべきでないサイトや、証明書ピンニングを使うアプリの通信先が該当します。CLI で特定 FQDN を除外する例は次のとおりです。組み込みの deep-inspection プロファイルは版によって編集できないため、複製したプロファイルを編集してポリシーに割り当てます。

config firewall address
    edit "exempt-www-example-com"
        set type fqdn
        set fqdn "www.example.com"
    next
end
config firewall ssl-ssh-profile
    edit "custom-deep-inspection"
        config ssl-exempt
            edit 1
                set type address
                set address "exempt-www-example-com"
            next
        end
    next
end

資産管理下で CA を配布できる端末にはディープインスペクション＋CA 配布、BYOD やゲスト Wi-Fi は証明書インスペクション（certificate-inspection）か除外で運用します。CA を持たない端末にディープインスペクションを掛け続けると、HSTS のサイトだけが恒常的に開けなくなります。

FortiGate管理画面そのもののHSTS：admin-hsts-max-age

「fortigate hsts」のもう 1 つの文脈は、FortiGate の管理画面が HSTS ヘッダーを返す件です。FortiOS 7.6.6 の CLI リファレンス（config system global）では、admin-hsts-max-age の既定値は 63072000 秒（2 年）、0 を設定するとブラウザの HSTS 記録をリセットすると記載されています。管理画面の証明書が自己署名のまま FQDN で開いていると、一度 HSTS を記憶したブラウザは警告を承認できず入れなくなります。正攻法は管理画面に正規の証明書を設定することで、一時的には IP アドレスで接続するか、net-internals で該当 FQDN を削除してから入ります。

config system global
    set admin-https-redirect enable
    set admin-hsts-max-age 0
end

管理画面を触るついでに、Fortinetの脆弱性まとめ｜FortiGateの悪用済みCVE一覧と影響確認・修正版・回避策【2026年10月】で管理インターフェースの公開範囲と修正版も点検してください。

サイト移転・DNS切り替え前の動作確認で出る場合

運営者側でよく起きるのが、サーバの引っ越しでネームサーバや A レコードを切り替える前に、PC の hosts ファイルを書き換えて新サーバを表示したときにこのエラーが出るケースです。旧サイトで HSTS を配信していた（または WordPress のプラグインやホスティング会社の設定で配信されていた）ため、ブラウザは HTTPS でしか接続しません。ところが新サーバにはまだそのドメインの正しい証明書が入っておらず、ホスト名の不一致や自己署名の証明書が返る。その結果、例外承認できずに止まります。WordPress 移行の全体手順はWordPress移行（サーバー引っ越し）の手順と注意点｜自力と代行の判断基準も解説にまとめています。

net-internals で記録を消せば HTTP で表示できることもありますが、これは自分のドメインを自分の端末で確かめるときだけに使う回避策で、preload 済みのドメインでは効きません。確実なのは、DNS を切り替える前に新サーバへ正しい証明書を入れておくことです。

新サーバの証明書確認：curlの–resolveによる接続先指定

ブラウザで見る前に、curl の --resolve で「このドメイン名をこの IP に向ける」指定をして、新サーバが返す証明書を確かめます。hosts ファイルを書き換えないので戻し忘れもありません。

curl -sS -o /dev/null --resolve www.example.com:443:203.0.113.10 https://www.example.com/
echo $?

macOS 標準の curl 8.7.1 で、www.example.com を別のドメイン用の証明書を返すサーバの IP へ向けて試すと、次のように終了コード 60 で止まりました。

curl: (60) SSL: no alternative certificate subject name matches target host name 'www.example.com'

これは新サーバが返す証明書とホスト名が合っていないという意味です。hosts で新サーバへ向けたブラウザも同じ証明書を受け取るので、そのドメインの HSTS を記憶していればエラーになります。-v を付けると subject と issuer が出るので、どの証明書が返っているかも分かります。終了コード 0 で返るようになってから DNS を切り替えます。

DNS切り替え前に証明書を発行する方法：DNS-01と証明書の移設

Let’s Encrypt でよく使う HTTP-01 チャレンジは、Let’s Encrypt の Challenge Types にあるとおり http://<ドメイン>/.well-known/acme-challenge/<TOKEN> を取りに来ます。DNS がまだ旧サーバを向いている間は、新サーバでこの検証は通りません。DNS-01 チャレンジは TXT レコードで検証するので、A レコードの向き先に関係なく新サーバ用の証明書を発行できます。DNS の TXT レコードを操作できない場合は、旧サーバの証明書と秘密鍵を新サーバへ移すか、ホスティング会社の「事前 SSL」系の機能を使います。いずれも、切り替えの瞬間に新サーバが正しい証明書を返している状態を先に作るのが要点です。

HSTSの仕組み：ヘッダーの3つのディレクティブとリダイレクトとの違い

Strict-Transport-Securityヘッダーの構文とmax-age・includeSubDomains・preload

サーバは HTTPS のレスポンスで次のヘッダーを返します。HTTP のレスポンスで返しても仕様上は無視されます。ディレクティブの一覧は MDN の Strict-Transport-Security リファレンスにもまとまっています。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

ディレクティブ	意味	注意点
max-age（必須）	HTTPS 強制を記憶する秒数	受信のたびに再計算。0 で解除
includeSubDomains	全サブドメインにも適用	HTTP だけのサブドメインを巻き込む
preload	preload リスト申請の意思表示	書くだけでは登録されない

max-age=31536000 は 1 年です。2026年10月16日に実際のレスポンスを確かめると、github.com は max-age=31536000; includeSubdomains; preload を返していました。includeSubDomains は、社内の管理画面や HTTP でしか動かない機器の Web UI が同じドメインのサブドメインにぶら下がっていると、それらをブラウザから開けなくします。サブドメインを棚卸しし、HTTP でしか応答しないホストが残っているうちは付けません。

HTTPSリダイレクト（常時SSL化）とHSTSの守備範囲の違い

「301 で HTTPS へリダイレクトしているから HSTS は不要」というのは誤解です。リダイレクトは、最初の HTTP リクエストがネットワークに流れてから行われます。この最初の平文リクエストを乗っ取るのが SSLStrip 型の中間者攻撃で、リダイレクトでは防げません。HSTS が記憶されていれば、ブラウザはアドレスバーの入力を送信前に HTTPS へ書き換えるので、平文のリクエストが 1 度も出ません。初回訪問者のためのリダイレクトと、2 回目以降を守る HSTS は併用するもので、初回訪問すら守る手段が preload リストです。リダイレクトの種類と設定はリダイレクトとは？301・302・307・308の違いと.htaccess・Nginx・PHPでの設定方法で解説しています。

Apache・nginx・IIS・LaravelでHSTSヘッダーを付ける設定例

いずれも HTTP から HTTPS へのリダイレクトが済んでいることが前提で、HTTPS 側のレスポンスにだけ付けます。

Apache：alwaysによる4xx・5xx応答へのHSTSヘッダー付与

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

always を付けないと 4xx・5xx のレスポンスにヘッダーが付きません。違いは Apache 公式の mod_headers ドキュメントに記載があります。a2enmod headers での有効化も忘れがちです。.htaccess に書く場合は、対象ディレクトリで AllowOverride（FileInfo 以上）が有効でなければ読まれません。VirtualHost に直接書けるならそのほうが確実です。脆弱性対応とあわせて見直すならApache HTTP Server 2.4の脆弱性まとめ：CVE-2026-33523ほか2.4.67〜2.4.69の対応手順も確認してください。

nginx：add_headerの継承の落とし穴

server {
    listen 443 ssl;
    server_name example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

nginx 公式の ngx_http_headers_module にあるとおり、下位ブロック（location など）に add_header が 1 つでもあると、上位ブロックの add_header はそのブロックへ継承されません。server に HSTS を書き、特定の location にキャッシュ制御の add_header を足した瞬間に、その location だけ HSTS が消えます。HSTS の行を各 location にも書き直すか、1.29.3 以降なら add_header_inherit merge; で上位の値を下位の値に追加させる方法もあります。版の選び方はnginxの最新バージョンは1.31系（安定版1.30）｜確認方法・更新手順と変更点【2026年10月】を参照してください。

IIS 10：専用のHSTS設定とweb.configの二重付与

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

IIS 10.0 バージョン 1709 以降にはサイト単位の HSTS 専用設定（<hsts> 要素）があり、max-age・includeSubDomains・HTTP から HTTPS へのリダイレクトを指定できます。上の customHeaders は古い IIS 向けの書き方で、HTTP のレスポンスにも同じヘッダーを付けてしまいます。専用設定と併用すると二重付与になるので、1709 以降は専用設定に寄せます。

Laravel：TLS終端の背後で付ける場合のTrustProxies

ロードバランサやリバースプロキシで TLS を終端していると、アプリからは HTTP に見えて条件判定を誤ります。Laravel では TrustProxies で X-Forwarded-Proto を信頼させたうえで、ミドルウェアから付与します。

<?php
// app/Http/Middleware/AddHstsHeader.php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class AddHstsHeader
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        if ($request->secure()) {
            $response->headers->set(
                'Strict-Transport-Security',
                'max-age=31536000; includeSubDomains'
            );
        }

        return $response;
    }
}

静的ファイルがアプリを通らない構成では、アプリで付けると漏れが出ます。Web サーバ層の 1 か所にまとめるほうが二重付与と条件漏れを避けられます。

HSTSを無効化する手順：max-age=0の配信とpreload削除申請

ヘッダー由来のHSTS解除：max-age=0の配信とHTTPSの維持期間

ヘッダーを削除するだけでは止まりません。すでに記憶している訪問者のブラウザは、max-age の残り期間ずっと HTTPS を強制し続けます。

HTTPS で Strict-Transport-Security: max-age=0 を配信する。RFC 6797 の 6.1.1 節で、max-age が 0 なら既知の HSTS ホストとして扱うのをやめると定められている。
最後に長い max-age（例：1 年）を配信した日から、その期間が過ぎるまで HTTPS と max-age=0 の配信を続ける。途中で max-age を段階的に短くしても、その間に再訪しなかったブラウザには古い期限が残るため、この期間は短くならない。
期間が過ぎてから、ヘッダーの配信をやめる（HTTP へ戻すのもこの後）。

HTTPS を止めてから max-age=0 を出しても、ブラウザは HTTPS でしか接続しないため受け取れません。

preloadリストからの削除申請と6〜12週という時間

preload 登録済みのドメインは、hstspreload.org の削除フォームから申請します。要件は「hstspreload.org で登録済みか登録待ちであること」「有効な証明書で HTTPS を提供していること」「有効な HSTS ヘッダーを送っていること」「そのヘッダーに preload ディレクティブが含まれないこと」です。HSTS そのものをやめるなら、これに加えて max-age=0 を配信します。

公式の案内では、削除が Chrome 利用者の大半に届くまで 6〜12 週、他のブラウザではさらに長くかかります。ブラウザを更新しない利用者には届きません。preload は、社内とグループの全システムを恒久的に HTTPS だけで運用できると確信できるときにだけ申請してください。

HSTS設定後の確認：curlによるヘッダー確認とブラウザの記録照会

curl -sI https://example.com | grep -i strict-transport-security

# エラーページにも付いているか（Apache の always 漏れ検知）
curl -sI https://example.com/not-found-check | grep -i strict-transport-security

見るのは 3 点です。HTTPS のレスポンスにヘッダーが付いているか、404 などのエラーページにも付いているか、そしてブラウザに記憶されたか。最後の点は chrome://net-internals/#hsts で Query し、dynamic_sts_expiry に値が入っていれば記憶済みです。社内の FortiGate 配下から curl を打って証明書エラーで止まったら、-k で黙らせずに前述の openssl コマンドで発行者を確認してください。発行者が Fortinet や自社の CA なら経路での再署名、本来の認証局のままなら期限切れやホスト名の不一致など証明書そのものの問題です。

HSTS は通信経路を守る設定で、Web サーバの実装の欠陥は防げません。NGINX Rift（CVE-2026-42945）：影響条件の判定手順とPoC公開後の対応のような脆弱性はバージョン更新でしか塞げません。HSTS を含むセキュリティヘッダー、証明書チェーン、TLS 設定を第三者の目でまとめて点検するなら、脆弱性診断・セキュリティ診断で公開サーバの設定不備を洗い出す方法があります。TLS のバージョンや暗号スイートの基礎はTLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】が参考になります。

よくある質問

HSTS を解除するにはどうすればいいですか？

自分の端末だけなら、Chrome・Edge は chrome://net-internals/#hsts の「Delete domain security policies」でドメインを削除、Firefox は履歴から「このサイトを忘れる」、macOS の Safari は HSTS.plist を削除します。サイト側で解除するなら max-age=0 を元の max-age の期間だけ配信し続けます。

net-internals で削除してもエラーが消えないのはなぜですか？

主な理由は 3 つです。ドメインが preload リスト（static）に載っていて端末側では消せない、親ドメインの includeSubDomains が効いていて子ドメインの名前では消えない、サイトへの正常な接続で再登録された。いずれの場合も、証明書エラーという根本原因が残っていれば正常には表示されません。

しばらく待てばアクセスできるようになりますか？

原因がサイト側の証明書（期限切れや更新ミス）なら、運営者が直せば待つだけで開けるようになります。ログインが必要な Wi-Fi や端末の時計、社内の SSL インスペクションが原因なら、待っても直りません。別の回線で開けるかどうかで見分けます。

FortiGate を通すと特定のサイトだけ HSTS エラーになるのはなぜですか？

SSL ディープインスペクションで FortiGate が証明書を Fortinet_CA_SSL で再署名しており、端末がその CA を信頼していないためです。HSTS のないサイトは警告を承認して進めてしまうので、HSTS のあるサイトだけが開けなくなります。端末へ CA を配布するか、対象サイトを ssl-exempt で除外します。

Chrome の「常に安全な接続を使用する」のデメリットと、HSTSとの違いは何ですか？

別物です。HSTS はサーバの指示で特定ドメインに HTTPS を強制する仕組み、「常に安全な接続を使用する」はブラウザの判断で HTTPS を優先し、HTTP のサイトを開く前に警告を出す設定です。Google Security Blog（2025年10月）が予告したとおり、Chrome 154 のリリースノート（安定版 2026年9月22日）には「Ask before HTTP on by default」とあり、HTTP のサイトへ接続する前に確認する動作が既定になりました。既定になったのは公開サイト向けの方式で、プライベートなアドレスの社内サイトは対象外です。デメリットは、HTTP でしか配信されていない公開サイトを開くたびに確認が挟まることです。組織の端末ではポリシー HttpsOnlyMode で既定を変えられ、個人は設定をオフにすれば確認は止まります。