証明書チェーン検証の可視化

HTTPSでサイトを開くと、ブラウザは受け取ったサーバー証明書が「本物か」を確かめます。サーバー証明書 ← 中間CA ← ルートCA と署名をたどり、端末に内蔵された信頼の起点（ルートCA）まで届くかを検証し、さらに期限・ドメイン・失効も確認します。シナリオを切り替えて、「安全な🔒」になる場合と、なぜ警告が出るかを1ステップずつ確かめてください。

ブラウザの4つのチェック

🔍 検証中…

いま何を検証しているか

信頼の連鎖（チェーン・オブ・トラスト）とは

証明書は「1枚で完結」しているわけではありません。サーバー証明書は中間CAが署名し、中間CAはルートCAが署名する、という連鎖（チェーン）になっています。ブラウザは受け取ったサーバー証明書から署名をたどり、端末やブラウザに最初から組み込まれているルートCA（＝無条件に信頼する“起点”）まで到達できれば、「正しく発行された本物」と判断します。各段の署名は、1つ上のCAの公開鍵で検証します。

ポイントは、ルートCAの証明書も“自己署名”だという点です。にもかかわらず信頼されるのは、それが端末の「信頼ストア（トラストストア）」に登録済みだからです。逆に、どこの信頼ストアにも無い証明書が自分で自分に署名しても（＝ただの自己署名証明書）、連鎖の起点にたどり着けず信頼されません。ここが混同しやすい核心です。

ブラウザが確認する4つのこと

チェック	内容	失敗すると（Chromeの例）
信頼の連鎖	署名をたどって信頼ストアのルートCAまで到達できるか	NET::ERR_CERT_AUTHORITY_INVALID
有効期限	現在日時が証明書の有効期間内か	NET::ERR_CERT_DATE_INVALID
ドメイン名(SAN)	証明書のSANとアクセス先のホスト名が一致するか	NET::ERR_CERT_COMMON_NAME_INVALID
失効の有無	CAが無効化(revoke)していないか（OCSP/CRL）	NET::ERR_CERT_REVOKED

これらは上から順に確認され、1つでも失敗した時点で検証は中断して警告になります（本ツールもその挙動に合わせています）。逆に言えば、警告が出たら「4つのどれで引っかかったか」を切り分ければ原因が分かります。

ドメイン名は「SAN」で確認される（CNは使われない）

「証明書のドメイン名」というと昔はコモンネーム(CN)を指しましたが、現在の主要ブラウザはCNを無視し、SAN（Subject Alternative Name）だけで一致を判定します。1枚の証明書に example.com と www.example.com のように複数のドメインを載せられるのもSANの働きです。アクセスしたホスト名がSANのどれとも一致しなければ、証明書が本物でも「別サイト用」として拒否されます。

有効期限と自動更新

証明書には有効期限があり、切れると（連鎖や署名が正しくても）警告になります。無料CAのLet's Encrypt は有効期間が90日と短く、そのぶん自動更新して運用するのが一般的です。「証明書の期限切れでサイトが見られない」障害は、この自動更新の停止が原因のことが多いです。

失効（revoke）— 期限前に無効化する仕組み

秘密鍵が漏れたなど「期限内でも信用できなくなった」場合に、CAが証明書を失効(revoke)できます。ブラウザはCRL（失効リスト）やOCSP（オンラインで1枚ずつ問い合わせ）で失効を確認します。毎回OCSPに問い合わせると遅く・プライバシー面の懸念もあるため、サーバーが失効情報を代わりに添えるOCSPステープリングもよく使われます。

自己署名証明書はなぜ警告が出るのか

自己署名証明書は「自分で自分の身分証を発行」した状態で、第三者（信頼されたCA）の裏付けがありません。そのため信頼の連鎖をたどっても信頼ストアの起点に届かず、ブラウザは NET::ERR_CERT_AUTHORITY_INVALID を出します。社内・開発環境などで意図的に使う場合は、その証明書（またはローカルの認証局）を端末の信頼ストアに手動で登録すれば、その端末では警告が消えます（＝“信頼ストアにあるかどうか”がすべて、という裏返しです）。

基本情報技術者試験ではこう出る

「ディジタル証明書を発行するのは（→認証局CA）」「ルート証明書の役割」「証明書が無効と判断される条件（期限切れ・ドメイン不一致・信頼の連鎖をたどれない）」などが定番です。失効の確認方法（CRL・OCSP）や、公開鍵で暗号化し秘密鍵で復号／署名は秘密鍵で行い公開鍵で検証という対応関係も頻出。鍵の使い分けは当サイトのSSL/TLS証明書の可視化と合わせて整理すると確実です。