証明書エラーが無視できない原因 HSTS | SEの道標
トラブルシュート

証明書エラーが無視できない原因 HSTS

SSL 証明書の警告画面が表示される原因としては以下を参照ください。

SSL証明書エラー/警告の原因・理由と対処方法
証明書エラー警告がされた場合の対処法です。 症状 (Chrome, Edge, ...

警告画面は無視して進むことができるケースと無視できないケースがあります。この記事では後者が発生する理由について説明しますが、結論として、解決方法は上記 URL で説明されている「警告画面が表示されてしまう」理由を確認し、その原因を解消すること以外にありません。

症状

証明書エラー画面で「詳細設定」を押しても「~にアクセスする (安全ではありません)」と表示されず、証明書エラーを無視できない。

Chrome の場合、以下のように「データのやり取りが行われる前に Chrome によって接続が停止されたため、情報は引き続き保護されています。~では HSTS が仕様されているため、現在アクセスできません。通常、ネットワークエラーやネットワークへの攻撃は一時的なものです。しばらくするとページにアクセスできるようになります。」と表示されます。

Edge の場合、同様に「データ交換が行われる前に Microsoft Edge によって接続が停止されたため、ユーザーの情報は引き続き安全な状態です。現在、~を閲覧できません。この Web サイトでは HSTS が使用されています。通常、ネットワークのエラーや攻撃は一時的なものであるため、時間を置くとこのページを正常に使用できる可能性があります。」と表示されます。

原因

ブラウザ側で HSTS の機能が有効になっており、アクセス先の URL のサーバーから過去に HSTS のための http ヘッダー (具体例 Strict-Transport-Security: max-age=31536000) が付与された状態で正常にアクセスできていたが、現在は証明書エラーが発生したため。

HSTS とは、HTTP Strict Transport Security の略で、RFC6797 で定義されています。

主たる機能はブラウザに対して (http ではなく) https を強制する仕組みですが、証明書エラー警告を無視できなくすることについても言及されています。

RFC6797 の Section 12.1 にある通り、エラー時はユーザーが自力で救済するべきではなく、むしろサーバーエラーと同様に扱われるべき、としています。

これは、中間者攻撃を防ぐという目的のためです。

例えば、この事象を目にするときの多くは、UTM やプロキシ等の中間機器で「SSL/TLS を復号するケース」や「別の画面に https リダイレクトするケース」が想定されます。過去にブラウザであるサイトを見て HSTS の状態が記録された後、SSL/TLS 復号を行うシステムを導入し、そのシステムで使うルート証明書がクライアントにインストールされていない場合、このようなシナリオに陥ります。

このような場合、以下の手順に沿ってルート証明書をクライアントにインストールすれば解消されます。

【図解/Windows】ルート証明書のインストール方法と確認方法
デジタル証明書の確認 Windows でデジタル証明書のエラーが出た際、クライア...

ルート証明書の保存は下図の通り、「保護されていない通信」をクリック⇒「証明書が無効です」の横にあるポップアップロゴをクリック⇒表示された「証明書ビューア」の「詳細」タブの「証明書の階層」の一番上にあるもの (下図の例だと ISRG Root X1) を選択した状態で「エクスポート」をクリックします。

実験:Nginx で自己署名証明書で HSTS を設定した上で各ブラウザでの挙動の違いを確認

Nginx において自己署名証明書 (SANs=www.example.com) を作り、HSTS (add_header Strict-Transport-Security 'max-age=') を設定しました。

[/etc/nginx/nginx.conf]

# Settings for a TLS enabled server.

    server {
        listen       443 ssl http2 default_server;
        server_name  www.example.com;
        root         /usr/share/nginx/html;

        ssl_certificate "/etc/pki/nginx/server.crt";
        ssl_certificate_key "/etc/pki/nginx/private/server.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphers PROFILE=SYSTEM;
        ssl_prefer_server_ciphers on;

        add_header Strict-Transport-Security 'max-age=31536000';
~~~

クライアントに自己署名証明書を「信頼されたルート証明機関」としてインストールし、設定を読み込ませた上で、ルート証明書をアンインストールし再びアクセスをしてみると、Edge の場合は警告を無視できなくなりましたが、Chrome については警告を無視できました。

Chrome は「chrome://net-internals/#hsts」にて対象サイトが HSTS の有効無効を確認できます。下図では www.example.com で Query を投げて「Not found」が返ってきており、HSTS が無効だと分かります。

上の「Add HSTS domain」のテキストボックスに「www.example.com」を入れ、横の「Add」ボタンを押すと HSTS が有効になり、Chrome で www.example.com へアクセスすると警告を無視できなくなりました。

じゃあこれは 1 つ 1 つ登録するのかというと、プリセットされているものもありました。例えば bing.com を先ほど同様 Query してみると HSTS 有効になっていることが分かります。詳細はよくわからないが、おそらく HSTS の preload として登録されているもののみが有効化されているのではないでしょうか。

HSTS は仕組み上、一度は該当サーバへアクセスしなければならないが、その最初の1回で http アクセスが発生する可能性があります。HSTS preload ではこれをリスクと考え、初回から https アクセスにさせるために申請ベースで HSTS 対応サイトを登録できるようになっており、ブラウザはこのリストを使って初回アクセス時も https アクセスを試みます。

登録は以下サイトから実施できます。

HSTS Preload List Submission

なお、Firefox は HSTS とは関係ないところで、そもそも「自己署名証明書」を「サーバ証明書」として使うことがダメのよう。これが原因のような気がするが、うまく検証できず、断念。(下図のように「自己署名をしているためこの証明書は信頼されません。」と表示される。)

コメント

タイトルとURLをコピーしました