HSTSが使用されているためアクセスできない原因と解除方法｜HSTSの仕組み・設定・無効化まで

ブラウザに「HSTS が使用されているため、現在アクセスできません」と表示され、いつもの「詳細設定 → アクセスする（安全ではありません）」も出てこない。これはブラウザの不具合ではなく、そのドメインに対して HSTS（HTTP Strict Transport Security）が効いていて、証明書エラーの例外承認そのものが封じられている状態です。この記事では、閲覧者としてすぐ通したい場合の解除手順、消えないときの見分け方、そしてサイト運営者として設定・無効化する場合の手順を、RFC 6797 と Chromium・hstspreload.org の公式仕様に沿って整理します。

まとめ

• このエラーの正体は「証明書エラー ＋ HSTS で例外承認が禁止」。証明書が正しくなければ、HSTS を消しても根本解決にはならない。
• 自分の端末だけ通したいなら、Chrome / Edge は chrome://net-internals/#hsts（Edge は edge://net-internals/#hsts）の「Delete domain security policies」でドメインを削除する（手順へ）。
• 削除しても直らないなら、そのドメインは preload リスト（static）に載っている可能性が高い。static エントリは端末側では消せず、hstspreload.org への削除申請が必要になる。
• 特定のネットワークでだけ再現する場合は、SSL 可視化する UTM・プロキシ、Wi-Fi のキャプティブポータル、期限切れ証明書が典型的な原因。ブラウザ設定をいじる前にネットワーク側を疑う。
• サイト側で解除するには max-age=0 を配信する。ただし preload 登録済みドメインは、削除申請から利用者へ行き渡るまで 6〜12 週かかる（不可逆に近い）。

以下、エラーの原因から順に、閲覧者側の手順とサーバ運営者側の設定を分けて説明します。

「HSTS が使用されているため、現在アクセスできません」が出る原因

HSTS有効時のブラウザ動作 — HTTPSへの内部書き換えと例外承認の禁止

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

• HTTP でのアクセスを、サーバへ問い合わせる前に HTTPS へ内部的に書き換える（ネットワークに HTTP のリクエストを出さない）。
• TLS ハンドシェイクで証明書の検証に失敗したら、そこで通信を打ち切る。ユーザーによる例外承認を認めない。

したがってこのエラーは、証明書検証の失敗（期限切れ、ホスト名不一致、自己署名、社内 CA が未インストール、途中の機器による差し替え）が起きたときに、HSTS が「無視して進む」を封じた結果として現れます。警告文でネットワーク攻撃の可能性に触れられるのはこのためですが、業務環境で遭遇するケースでは証明書・中間装置の設定に起因していることが少なくありません。

「アクセスする（安全ではありません）」のリンクが出ない理由

通常の証明書エラー画面には「詳細設定」から先へ進むリンクがあります。HSTS が有効なドメインではこのリンク自体が表示されません。仕様上、HSTS は証明書エラーをユーザーが上書きできないものとして扱うためです。裏を返せば、リンクが出ないこと自体が「このドメインは HSTS が効いている」ことの判別材料になります。

なお Chrome の警告画面でキーワードを打ち込むバイパス（thisisunsafe）が知られていますが、これは開発者向けの一時回避で、Chrome 側が予告なくキーワードを変更してきた経緯があります。HSTS が効いているドメインの警告画面は本来ユーザーが上書きできない設計のため、この方法でも通らないことがあります。確実なのは次章の net-internals での削除であり、業務端末や金融機関・社内システムへのアクセスでバイパス語を常用する運用は避けてください。

ブラウザ別 HSTS の解除手順

Chrome・Edge：net-internals で該当ドメインを削除する

ヘッダー由来で記憶された HSTS（dynamic エントリ）は、端末側から削除できます。

1. アドレスバーに chrome://net-internals/#hsts（Edge は edge://net-internals/#hsts）を入力して開く。
2. 「Query HSTS/PKP domain」に対象ドメイン（例 example.com）を入れて Query し、状態を確認する。
3. 「Delete domain security policies」の Domain 欄に同じドメインを入れて Delete を押す。
4. ブラウザを再起動して、対象サイトへアクセスし直す。

Query の結果に static 側の項目（static_sts_domain）が返ってきた場合は後述の preload 判定へ、dynamic 側（dynamic_sts_domain）だけなら削除で通ります。ただしサイトが HSTS ヘッダーを送り続けている限り、次にアクセスした瞬間に再登録されます。証明書の問題が直っていなければ、削除は数分の延命にしかなりません。

Firefox・Safari：プロファイルとコンテナからの削除

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

Safari（macOS）は ~/Library/Cookies/HSTS.plist、サンドボックス化された環境では ~/Library/Containers/com.apple.Safari/Data/Library/Cookies/HSTS.plist に記憶が保存されます。Safari を終了してから削除しますが、後者のパスはフルディスクアクセスの許可が必要です。iOS の Safari にはドメイン単位の削除手段がなく、「設定 → Safari → 履歴と Web サイトデータを消去」で全サイトぶんまとめて消すことになります。

削除しても直らない場合：static（preload）かどうかを見分ける

ここが多くの記事で抜け落ちる分岐点です。HSTS の記憶には 2 種類あります。

preload リストはブラウザのバイナリに同梱されているため、net-internals で Delete を押しても static エントリは消えません。.dev や .app のようにTLD ごと preload されているケースもあり、この場合はそのドメインで HTTP や自己署名証明書を使うこと自体が不可能です。開発環境のドメインに .dev を使っていて突然通らなくなったというケースはこれに該当し、対処は「ブラウザを直す」ではなく「ドメインを .test や .localhost へ変える」「正規の証明書を入れる」になります。

社内・特定ネットワークだけで多発するときの原因切り分け

同じサイトが自宅では開けるのに会社では HSTS エラーになる、といった場合は、ブラウザではなく経路上の機器を疑います。判断が早いのは次の順序です。

• SSL 可視化（SSL インスペクション）装置：FortiGate や Cisco Umbrella、プロキシ型のセキュリティ製品は、通信を復号するために自前の CA で証明書を差し替えます。その CA 証明書が端末に配布されていないと証明書エラーになり、HSTS サイトでは例外承認できずこのエラーになります。対処は端末への CA 証明書配布か、対象ドメインを可視化の対象外にすること。
• Wi-Fi のキャプティブポータル：ホテルや空港の認証前ネットワークは、最初の HTTP 通信を認証ページへ横取りします。HSTS サイトはそもそも HTTP を出さないので横取りが証明書エラーとして現れます。neverssl.com のような HTTPS 化していないサイトを開いて認証を先に済ませれば解決します。
• 証明書の期限切れ・チェーン不備：サイト側の失効。openssl s_client -connect example.com:443 や SSL Labs で有効期限と中間証明書を確認します。TLS ライブラリ側の更新事情はOpenSSL 4.0が2026年4月リリースへ至る背景とバージョン3系からの転換点も参考になります。
• 時計のずれ：端末の日時が大きくずれていると証明書が「まだ有効でない／期限切れ」と判定されます。仮想マシンやキオスク端末で起きやすい。

この 4 つを潰しても再現するなら、対象ドメインの証明書そのものが壊れています。閲覧者側でできることはなく、サイト運営者の対応待ちです。

HSTS の仕組みとディレクティブ

Strict-Transport-Security ヘッダーの構文

サーバは HTTPS のレスポンスで次のヘッダーを返します（HTTP のレスポンスで返しても仕様上は無視されます）。

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

max-age=31536000 は 1 年です。preload に申請するなら 1 年以上が要件で、実務では 2 年（63072000）を設定している大手サイトも多くあります。

HTTPS リダイレクト（常時SSL化）との違い

「301 で HTTPS へリダイレクトしているから HSTS は不要」と誤解されがちですが、守っている範囲が違います。リダイレクトは最初の 1 回の HTTP リクエストがネットワークに流れてから行われます。この最初の平文リクエストを乗っ取るのが SSLStrip 型の中間者攻撃で、リダイレクトだけでは防げません。HSTS が効いていれば、ブラウザはサーバに問い合わせる前にアドレスバーの入力を HTTPS へ書き換えるため、平文のリクエストが 1 度も出ません。両者は排他ではなく、初回訪問者のためのリダイレクトと、2 回目以降を守る HSTS を併用するのが正解です。初回訪問すら守りたい場合の答えが preload リストです。

サーバ別の HSTS 設定

いずれもリダイレクト設定（HTTP → HTTPS）が済んでいることが前提です。HTTPS 側のレスポンスにだけ付けます。

Apache（.htaccess / VirtualHost）

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

always を付けないと 4xx・5xx のレスポンスにヘッダーが付かず、エラーページ経由の初回訪問で HSTS が記憶されません。mod_headers の有効化（a2enmod headers）も忘れがちです。.htaccess に書く場合は、対象ディレクトリに対して AllowOverride が有効（FileInfo 以上）でなければ設定自体が読まれない点に注意してください。VirtualHost に直接書けるなら、そちらのほうが確実です。Apache 側の脆弱性対応と合わせて設定を見直すならApache HTTP Server 2.4の脆弱性まとめ：CVE-2026-33523ほか2.4.67/2.4.68の影響範囲と対応手順も確認してください。

nginx

server {
    listen 443 ssl;
    server_name example.com;

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

nginx の add_header には継承の落とし穴があります。下位ブロック（location など）に add_header が1つでも書かれていると、上位ブロック（http / server）の add_header はそのブロックへ一切継承されません。server に HSTS を書き、特定の location にキャッシュ制御用の add_header を足した瞬間、その location だけ HSTS が消えるという事故が起きます。設定後は必ず各パスの実レスポンスで確認してください。バージョン選定はnginx 1.29.7が2026年3月にリリースされた背景と1.29系列の全体像を参照。

IIS（web.config）

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

IIS 10（Windows Server 2019 以降）には HSTS の専用設定項目があり、サイト単位の「HSTS」ダイアログから max-age と includeSubDomains、リダイレクトの扱いを指定できます。web.config の customHeaders は HTTP のレスポンスにも同じヘッダーを付けてしまう（仕様上ブラウザは無視しますが）ため、専用機能と併用すると二重付与になります。どちらか一方に寄せ、IIS 10 以降なら専用の HSTS 設定を使ってください。

アプリケーション側で付ける場合（Laravel など）

ロードバランサやリバースプロキシで TLS を終端していると、アプリからは HTTP に見えてヘッダーが正しく付かないことがあります。Laravel なら TrustProxies で X-Forwarded-Proto を信頼させたうえで、ミドルウェアからレスポンスヘッダーを付与します。

// app/Http/Middleware/AddHstsHeader.php
public function handle($request, Closure $next)
{
    $response = $next($request);

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

    return $response;
}

$request->secure() が true を返すには、bootstrap/app.php（Laravel 10 以前は TrustProxies ミドルウェア）でプロキシと X-Forwarded-Proto ヘッダーを信頼するよう設定しておく必要があります。とはいえ、Web サーバ層（Apache / nginx）で 1 か所に集約するほうが、二重付与や条件漏れを避けられます。アプリで付けるのは、静的ファイルを含む全レスポンスがアプリを通る構成に限った話です。

HSTS を無効化・解除する（サイト運営者側）

ヘッダー由来（dynamic）の解除：max-age=0

HSTS を止めるときにヘッダーを削除するだけでは不十分です。ヘッダーを消しても、すでに記憶している訪問者のブラウザは max-age の残り期間ずっと HTTPS を強制し続けます。正しい手順は次のとおりです。

1. まず max-age を段階的に短くする（1 年 → 1 日 → 数分）。訪問者は再訪のたびに短い値で上書きされるため、影響範囲を絞りながら降りられます。
2. HTTPS で Strict-Transport-Security: max-age=0 を配信する（記憶を打ち消す「knockout」）。
3. 段階的に短くしていない場合は、最長の max-age 期間（例：1 年設定なら 1 年）ほど knockout の配信を続け、訪問者の記憶が上書きされるのを待つ。
4. そのうえでヘッダーの配信を停止する。

この間も HTTPS 自体は正常に提供し続ける必要があります。HTTPS を止めてから max-age=0 を配信しようとしても、ブラウザは HTTPS でしか接続しないため打ち消しヘッダーを受け取れません。

preload リストからの削除

preload 登録済みドメインは、hstspreload.org の削除フォームから申請します。要件は「有効な証明書で HTTPS を提供している」「配信している HSTS ヘッダーに preload ディレクティブが含まれていない」ことの 2 つです。HSTS そのものを完全にやめたい場合は、これに加えて前項の max-age=0（knockout）を配信します。preload リストから外すだけなら HSTS を維持したままでも申請できます。

問題は時間です。公式の案内では、削除が Chrome 利用者の大半に届くまで 6〜12 週、他のブラウザではさらに長くかかり、ブラウザを更新しない利用者には永久に届きません。preload は事実上、取り消しの効かない片道切符と考えるべきです。

設定後の確認：curl と net-internals での検証

ブラウザの見た目では確認になりません。レスポンスヘッダーを直接見ます。

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

# 出力例:
# Strict-Transport-Security: max-age=31536000; includeSubDomains

確認の観点は 3 つです。

• HTTPS のレスポンスにヘッダーが付いているか（HTTP 側に付いていても無視される）。
• エラーページ（404 など）にも付いているか（Apache の always 漏れ検知）。
• ブラウザに記憶されたか。Chrome の chrome://net-internals/#hsts で Query して dynamic_sts_expiry が入っていれば記憶済みです。

preload 申請の可否は hstspreload.org のフォームにドメインを入力すると要件チェックの結果が返ります。

導入前に必ず確認すべき落とし穴

HSTS は「とりあえず入れておくと安全」という類の設定ではありません。次の 2 点を確認せずに入れると、自社のサービスを自分で止めることになります。

includeSubDomains は、全サブドメインが HTTPS 化されていない限り付けてはいけません。 社内向けの管理画面、古い検証環境、HTTP でしか動かない機器の Web UI が *.example.com にぶら下がっていると、それらは記憶が切れるまでブラウザから開けなくなります。ワイルドカード配下のサブドメインを棚卸しし、HTTP でしか応答しないホストが 1 つでも残っているなら、まずそちらを HTTPS 化してからにしてください。

preload は、社内・グループの全システムが恒久的に HTTPS のみで運用できると確信できる場合にだけ申請してください。 前述のとおり削除には 6〜12 週かかり、その間ずっと「HTTPS でしか接続できない」状態が続きます。逆に、金融・EC・認証を扱うサービスで、初回訪問時の平文リクエストまで防ぎたいという明確な要件があるなら、preload は投資に見合います。判断基準は「HTTPS 化の完了度」であって、セキュリティ意識の高さではありません。

なお、Web サーバやミドルウェアの脆弱性は HSTS では防げません。NGINX Rift（CVE-2026-42945）が緊急とされる理由と発見の経緯のような実装側の欠陥は、ヘッダー設定ではなくバージョン更新でしか塞げない点は分けて考えてください。

よくある質問

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

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

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

2 つの可能性があります。ひとつはドメインが preload リスト（static エントリ）に載っているケースで、この場合ブラウザ内蔵のリストなので端末側では消せません。もうひとつは、サイトが HSTS ヘッダーを送り続けていて再訪した瞬間に再登録されているケースです。いずれにせよ、証明書エラーという根本原因が残っているなら解除しても正常には表示されません。

HSTS を有効にするにはどうすればいいですか？

HTTPS のレスポンスに Strict-Transport-Security: max-age=31536000 を付けます。Apache は Header always set、nginx は add_header ... always、IIS は web.config かサイト単位の HSTS 設定です。全サブドメインの HTTPS 化が済むまで includeSubDomains は付けないでください。

Chrome の「常に安全な接続を使用する」を有効にするデメリットはありますか？

この設定は HSTS とは別物で、サーバの指示ではなくブラウザ側の判断で HTTPS 接続を優先し、HTTP のサイトを開く前に警告を出すものです。Google のセキュリティブログ（2025年10月）によると、Chrome 147（2026年4月）で拡張保護機能の利用者に先行適用され、Chrome 154（2026年10月）で既定オンになる予定です。警告の対象は公開サイトに限られ、社内イントラや private IP、ローカルアドレスは対象外とされています。したがって「社内の HTTP システムが軒並み警告される」ことは既定設定では起きません。デメリットは、HTTP でしか配信されていない外部の公開ページ（古い資料サイトなど）を開くたびに確認が挟まる点で、設定からオフにすることは可能です。

HSTS で防げる攻撃と、防げない攻撃は何ですか？

防げるのは、平文の HTTP リクエストを狙う SSLStrip 型の中間者攻撃と、証明書エラーをユーザーに承認させて割り込む攻撃です。HTTP のリクエストが 1 度も出なくなるため、Secure 属性の付いていない Cookie が平文で送出される事故も併せて防げます。防げないのは、サーバ実装の脆弱性、XSS や SQL インジェクションといったアプリ層の攻撃、そして preload 未登録ドメインへの「その端末での初回アクセス」です。

関連記事

• Apache HTTP Server 2.4の脆弱性まとめ：CVE-2026-33523ほか2.4.67/2.4.68の影響範囲と対応手順
• nginx 1.29.7が2026年3月にリリースされた背景と1.29系列の全体像
• OpenSSL 4.0が2026年4月リリースへ至る背景とバージョン3系からの転換点
• NGINX Rift（CVE-2026-42945）が緊急とされる理由と発見の経緯