Chrome だけ TLS 証明書エラーになる場合、最初に疑うべきなのは Chrome そのものではなく、サーバーが返している証明書、証明書チェーン、名前解決、信頼ストア、ブラウザ側の状態の差です。
Firefox や Safari では開けるのに Chrome では開けないと、Chrome の不具合のように見えます。しかし実際には、他のブラウザが中間証明書のキャッシュや OS 側の補完で通しているだけで、サーバー側の証明書チェーンが不完全な場合もあります。
この記事では、Chrome だけで証明書エラーになる時に、どの順番で原因を切り分けるかを整理します。単に警告を回避するのではなく、証明書チェーン、SAN、HSTS、独自 CA、Certificate Transparency、Secure DNS、キャッシュのどこに差があるのかを見ることが重要です。
書籍
暗号技術入門 第 3 版 秘密の国のアリス
公開鍵暗号、電子署名、証明書など、TLS や内部 PKI の前提になる暗号技術を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まずエラー名を見る
Chrome の証明書エラーは、画面上の説明だけでなく、エラーコードを見ると原因を絞りやすくなります。代表的には次のようなものがあります。
| Chrome のエラー例 | 疑う原因 | 確認すること |
|---|---|---|
| NET::ERR_CERT_AUTHORITY_INVALID | 発行元 CA を信頼できない | 独自 CA、社内 CA、中間証明書、Chrome の信頼ストア |
| NET::ERR_CERT_COMMON_NAME_INVALID | 証明書の名前がアクセス先と合っていない | Subject Alternative Name、FQDN、リダイレクト、SNI |
| NET::ERR_CERT_DATE_INVALID | 証明書の期限や端末時刻がおかしい | 証明書の Not Before / Not After、端末の日時、NTP |
| NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED | Certificate Transparency 要件を満たしていない | SCT、公開 CA 証明書、Chrome の CT 要件 |
| NET::ERR_CERT_REVOKED | 証明書が失効扱いになっている | 失効情報、証明書再発行、古い中間証明書 |
同じ「証明書エラー」でも、原因はかなり違います。特に Chrome だけで発生している場合は、証明書そのものだけでなく、Chrome がどの信頼ストアや検証ロジックを使っているか、過去のキャッシュや HSTS の影響を受けていないかも見ます。
一番多いのは証明書チェーンの不備
Chrome だけで TLS 証明書エラーになる時、実務でまず確認したいのは証明書チェーンです。サーバー証明書だけでなく、正しい中間証明書をサーバーが提示しているかを見ます。
たとえば、サーバー証明書の issuer が G4 の中間 CA なのに、サーバー側では古い G3 の中間証明書を返しているような構成では、証明書チェーンとしては不整合です。他のブラウザが AIA やキャッシュで補完できる場合でも、Chrome ではエラーとして顕在化することがあります。
重要なのは、ブラウザが補完してくれることを前提にしないことです。サーバーは、leaf 証明書から必要な中間証明書まで、検証に必要なチェーンを正しい順序で提示するべきです。
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_errorこの確認では、サーバーがどの証明書を返しているか、issuer と subject がつながっているか、最後に Verify return code が 0 になるかを見ます。
SAN とアクセス先 FQDN を確認する
次に確認するのは、アクセスしている FQDN と証明書の Subject Alternative Name が一致しているかです。古い説明では Common Name と書かれることもありますが、現在の証明書検証では SAN が重要です。
たとえば、証明書には www.example.com だけが入っているのに、Chrome では example.com へアクセスしている場合、名前が一致しません。リダイレクト、SNI、リバースプロキシ、仮想ホストの設定によって、想定と違う証明書が返されている場合もあります。
- アクセスしている FQDN が証明書の SAN に含まれているか
- www あり / なしの両方を証明書に含める必要があるか
- SNI によって正しい仮想ホストの証明書が返っているか
- HTTP から HTTPS へのリダイレクト先が想定通りか
- IPv4 と IPv6 で別の証明書が返っていないか
独自 CA や社内 CA は Chrome の信頼ストア差を見る
社内サイト、検証環境、内部向け HTTPS では、独自 CA や社内 CA を使うことがあります。この場合、Firefox では開けるのに Chrome では開けない、またはその逆が起きることがあります。
理由は、ブラウザや OS によって信頼するルート証明書の扱いが異なるためです。Chrome はプラットフォームや設定によって Chrome Root Store や OS 側の証明書ストア、管理ポリシーの影響を受けます。Firefox は独自の証明書ストアを持つため、同じ端末でも結果がずれることがあります。
したがって、独自 CA を使う場合は、証明書を「インストールしたつもり」ではなく、Chrome が実際にその CA を信頼しているかを確認する必要があります。端末単位、ユーザー単位、管理ポリシー単位で入っている場所が違うと、ブラウザごとの差になります。
HSTS とキャッシュで Chrome だけ残ることがある
証明書を直した後も Chrome だけエラーが残る場合、HSTS やキャッシュも確認します。HSTS は、過去にそのサイトへ HTTPS で接続した情報をもとに、以後 HTTP ではなく HTTPS を強制する仕組みです。
HSTS 自体は安全性を高める仕組みですが、検証環境や内部サイトで証明書を頻繁に差し替えている場合、古い状態が Chrome 側に残っているように見えることがあります。ただし、HSTS を消せばよいという話ではありません。まずサーバー側の証明書、チェーン、名前、CA 信頼を正しく直すことが先です。
そのうえで、特定端末の Chrome だけで再現するなら、Chrome の証明書表示、キャッシュ、HSTS 状態、プロファイル差、シークレットウィンドウ、別端末での再現性を確認します。
Secure DNS や名前解決の差も確認する
Chrome だけ接続先が違うように見える場合は、Secure DNS、いわゆる DoH の設定や名前解決経路も確認します。証明書エラーは TLS の問題として見えますが、実際には Chrome が別の IP アドレスへ到達しており、想定と違う証明書を受け取っている場合があります。
特に社内 DNS、スプリット DNS、検証用 FQDN、IPv4 / IPv6 の両方を使う環境では、Chrome、Firefox、OS の名前解決結果が一致しているかを見ます。証明書チェーンや SAN を確認する前提として、そもそも同じサーバーに接続しているかを切り分ける必要があります。
Certificate Transparency が関係する場合
公開 CA から発行された証明書では、Certificate Transparency も Chrome の証明書検証に関係します。CT は、公開 CA が発行した証明書を監査可能なログへ記録する仕組みです。
通常の公開証明書で CT 要件を満たしていない場合、Chrome では NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED のようなエラーになることがあります。一方で、社内 CA や独自 CA の証明書では、公開 Web PKI と同じ CT の話ではなく、まずその CA を Chrome が信頼しているかが問題になります。
つまり、Chrome だけのエラーでも、公開サイトなのか、社内 CA なのか、検証環境なのかで見る場所が変わります。公開サイトなら CT や公開 CA の発行状態、内部サイトなら CA 配布と信頼ストアを優先して確認します。
確認順序
Chrome だけで証明書エラーになる場合、次の順番で見ると原因を切り分けやすくなります。
- Chrome のエラーコードを確認する
- アクセスしている FQDN と証明書の SAN を照合する
- サーバーが正しい leaf 証明書と中間証明書を返しているか確認する
- IPv4 と IPv6、別ポート、別仮想ホストで証明書が違わないか確認する
- 独自 CA や社内 CA を Chrome が信頼しているか確認する
- HSTS、キャッシュ、Chrome プロファイル差、Secure DNS の影響を確認する
- 公開証明書の場合は Certificate Transparency や CA 側の状態を確認する
この順序で見ると、ブラウザの違いに引っ張られず、サーバー側の問題、証明書発行の問題、端末側の信頼設定、Chrome 側の状態を分けて確認できます。
まとめ
Chrome だけ TLS 証明書エラーになる場合でも、原因が Chrome だけにあるとは限りません。他のブラウザが中間証明書のキャッシュや OS 側の補完で通しているだけで、サーバー側の証明書チェーンが不完全なことがあります。
まず見るべきなのは、Chrome のエラーコード、証明書の SAN、サーバーが提示する証明書チェーン、独自 CA の信頼状態、HSTS やキャッシュの影響です。警告を回避するのではなく、どの検証段階で失敗しているのかを分けて見る必要があります。
運用上は、ブラウザの補完に依存せず、サーバー側で正しい証明書と中間証明書を提示することが基本です。Chrome だけで先に問題が見える場合でも、それは隠れていた証明書運用の不備が表面化しただけかもしれません。
参考情報
参考：
関連する記事
あわせて読みたい：
