TLSにおけるブラウザの証明書のチェック

Last updated at 2026-03-27Posted at 2026-03-26

SSL/TLS通信で、ブラウザがどのようにサーバ証明書をチェックしているかを記述します。

1. 前提

本記事で説明する内容は、RFC 5280 に定義された Path Validation Requirements（経路検証要件）をベースにしています。

ただし、RFC 5280 は「最低限満たすべき検証要件」を定義したものであり、実際のブラウザやOSはこれに加えて独自の検証（拡張・最適化）を行っています。

そのため

RFCの内容＝理論上の検証仕様
ブラウザの挙動＝ RFC + 実装依存の追加チェック

という関係になります。

2. RFC 5280 における Path Validation Requirements（経路検証要件）

ブラウザはTLSハンドシェイクの中でサーバー証明書を受け取り、「この証明書が信頼できること」を判断します。

2.1. 証明書チェーンの構築（Path Construction）

ブラウザはサーバーから送られてきた以下の証明書を受け取ります。

サーバー証明書（leaf）
中間証明書（intermediate）※複数の場合あり

そしてブラウザ自身が持つ 信頼されたルート証明書ストア から、ルート証明書（信頼ストアに登録されたCA） を探し、「leaf → Intermediate → root」の完全なチェーンを構築します。

2.2. デジタル署名の検証

チェーンが構築できたら、各証明書について次を確認します。

証明書の署名が上位CAの公開鍵で検証できること（署名アルゴリズムおよびハッシュを含む）

これは X.509証明書 の署名検証で、「CAが本当にこの証明書を発行していること」を確認する工程です。

2.3. 有効期限のチェック

有効期限をチェックします。

Not Before 〜 Not After の範囲内であること
期限切れならエラー（ブラウザ警告）

※補足：
ルート証明書については実装依存であり、多くのブラウザでは「信頼ストアに登録されていること」が優先されるため、期限切れでも直ちにエラーとならない場合があります。

2.4. ホスト名（SAN）の一致確認（※RFC 5280の対象外）

アクセスしているURLのホスト名が、証明書の SAN（Subject Alternative Name） に含まれていることを確認します。

例：

証明書：www.example.com
アクセス：api.example.com → 不一致でエラー

※重要：
このホスト名検証は RFC 5280 では定義されておらず、別仕様（例：RFC 6125）に基づいています。

RFC 5280 → 証明書が正しいか
ホスト名検証 → 接続先として正しいか

という役割分担になります。

2.5. ルートCAが信頼されているかを確認

最終的にチェーンの一番上にある ルート証明書がブラウザに信頼されていること を確認します。

公開Webではブラウザにプリインストールされたルート CA が使われる
社内CAや自己署名ルートを使う場合は、クライアントに手動でインストールが必要

2.6. 失効状態（Revocation）の確認

ブラウザは以下の方法で証明書が失効していないことを確認します。

CRL（Certificate Revocation List）
OCSP（Online Certificate Status Protocol）

※ ただしブラウザやOSによって実装は異なります。

※実務上の注意：
ブラウザはOCSP/CRLの取得に失敗した場合でも、通信を継続する「ソフトフェイル」を採用することがあります。
また、Chrome や Firefox では独自の失効情報（CRLSets / OneCRL）を利用するなど、RFC 5280 とは異なる実装が行われています。

2.7. 証明書ポリシー・拡張の検証（RFC 5280 準拠）

証明書ポリシー・拡張の検証を行います。

Key Usage / Extended Key Usage
Basic Constraints（CA=TRUE かどうか）
Name Constraints
Policy Constraints

※近年のブラウザでは、RFC 5280 の要件に加え、より厳格な検証が行われる傾向があります。

2.8. 証明書チェーン全体の整合性チェック

チェーン全体に関わる要件をチェックします。

PathLenConstraint が破られていないこと
Policy が矛盾していないこと
Name Constraints が満たされていること
Critical Extensions がチェーン全体で矛盾していないこと
信頼ストアにあるルート証明書へ到達したこと

OKなら、TLSハンドシェイクが続行され、暗号化通信が開始されます。

3. ブラウザのCertificate Validation Steps（証明書検証ステップ）

※補足：
「Certificate Validation Steps」はRFC 5280の正式用語ではなく、Path Validation Requirements（経路検証アルゴリズム）を理解しやすくするために分解した説明用のステップです。

Root CA（ルート証明書、Root）
  └─ Intermediate CA（中間証明書、Intermediate）
        └─ Server Certificate（サーバ証明書、Leaf）

上記のサーバ証明書の場合、ブラウザの証明書検証は以下の順番で実施されます。

※補足：ブラウザ独自の追加検証

現代のブラウザでは、RFC 5280 に加えて以下の検証も行われます。

Certificate Transparency（CTログ）
SHA-1証明書の拒否
HSTS（HTTP Strict Transport Security）

これらはRFC 5280には含まれませんが、
実際のHTTPS通信では重要な役割を持ちます。

証明書チェーンの構築（Path Construction）
Server Certificate（サーバ証明書、Leaf）の検証
2.1. 署名検証
・サーバ証明書の署名を 中間証明書の公開鍵 で検証
・署名が壊れていれば即エラー
2.2. 有効期限チェック
・NotBefore / NotAfter が現在時刻に対して有効であること
・期限切れなら即エラー
2.3. SAN（Subject Alternative Name）によるホスト名検証
・アクセスしているドメインと一致すること
・不一致なら即エラー
※現代のブラウザでは、CNではなくSANが使用される
2.4. KeyUsage / EKU チェック
・Digital Signature / Key Encipherment などが正しいこと
2.5. 失効確認（OCSP / CRL）
・失効していればエラー（※ただし取得失敗時はソフトフェイルとなる場合あり）
・OCSP Stapling があればそれを優先
Intermediate CA（中間証明書、Intermediate）の検証
3.1. 署名検証
・中間証明書の署名を ルート証明書の公開鍵 で検証
3.2. 有効期限チェック
・中間証明書が期限切れなら即エラー（ここで止まる）
3.3. BasicConstraints チェック
・CA=TRUE であること
・pathLenConstraint が適切であること
3.4. KeyUsage チェック
・keyCertSignが含まれていること
3.5. 失効確認（OCSP / CRL）
Root CA（ルート証明書、Root）の検証
4.1. 署名検証（自己署名）
・形式的に自己署名を検証するが、信頼性判断には使われない
4.2. 有効期限チェック
・ルート証明書の有効期限の扱いは実装依存であり、多くのブラウザでは信頼ストアの登録状態が優先される
4.3. 信頼ストアに存在するかをチェック
・ここで初めて「信頼できるか」が決まる
・ルート証明書が信頼ストアに無ければ チェーン全体を信頼しない
証明書チェーン全体の整合性チェック

※補足：
説明上は Leaf → Intermediate → Root の順で記載していますが、RFC 5280 のアルゴリズム上は信頼アンカー（Root）を起点として検証状態を伝播させる形で定義されています。

4. 経路検証要件と証明書検証ステップの対応表

「Path Validation Requirements（経路検証要件） とブラウザの Certificate Validation Steps（証明書検証ステップ） の対応表」は以下となります。

No	経路検証要件	ブラウザでの証明書検証ステップ	説明
1	証明書チェーンの構築（Path Construction）	最初に一度だけ実行	Leaf → Intermediate → Root の“つながり”を作るだけ（信頼判断はまだしない）
2	デジタル署名の検証	各証明書ごとに実行（Leaf → Intermediate → Root）	Leaf は Intermediate の公開鍵で、Intermediate は Root の公開鍵で検証
3	有効期限のチェック	各証明書ごとに実行（ただし Root は緩い）	Leaf/Intermediate は厳格、Root は信頼ストア優先
4	ホスト名（SAN）の一致確認	Leaf のみ（※RFC 5280の対象外）	Intermediate/Root では行わない
5	ルート CA が信頼されているか？	Root に到達した時点で実行	信頼ストアにあるかどうかが最終判断
6	失効状態（OCSP/CRL）の確認	Leaf と Intermediate で実行	Root は失効確認しない
7	証明書ポリシー・拡張の検証（RFC 5280）	各証明書ごとに実行	KeyUsage（鍵の用途） / BasicConstraints（CA かどうか） / EKU（用途の制限） / Policy など
8	証明書チェーン全体の整合性チェック	最後にまとめて実行	全ての証明書が要件を満たしているか最終判断

まとめると、RFC 5280 は「証明書そのものが正しいか」を検証する仕様であり、ブラウザはそれに加えて「接続先として安全か（ドメイン・失効・ポリシーなど）」を独自に検証しています。

実際にブラウザでは以下の動作となります。

チェーン構築（Path Construction）（表のNo.1）
・「サーバ証明書 → 中間証明書 → ルート証明書」というつながりを作るだけ（信頼判断はまだしない）
Leaf（サーバ証明書）を検証
・署名検証（表のNo.2）
・有効期限（表のNo.3）
・SAN/CN（表のNo.4）
・KeyUsage（鍵の用途）/EKU（用途の制限）（表のNo.7）
・失効確認（表のNo.6）
Intermediate（中間証明書）を検証
・署名検証（表のNo.2）
・有効期限（表のNo.3）
・BasicConstraints（CA かどうか）（表のNo.7）
・KeyUsage（鍵の用途）（表のNo.7）
・失効確認（表のNo.6）
Root（ルート証明書）を検証
・自己署名チェック（表のNo.2）
・有効期限は読むが緩い（表のNo.3）
・信頼ストアにあるか（表のNo.5）
チェーン全体の整合性チェック（表のNo.8）
・PathLenConstraint が破られていないこと
・Policy が矛盾していないこと
・Name Constraints が満たされていること
・Critical Extensions がチェーン全体で矛盾していないこと
・信頼ストアにあるルート証明書へ到達したこと

5. 補足（KeyUsage / BasicConstraints / EKU について）

5.1. KeyUsage（鍵の用途）

公開鍵が どんな暗号操作に使えるか を定義します。

KeyUsage	意味
Digital Signature	TLS ハンドシェイクの署名に使える
Key Encipherment	RSA 鍵交換で鍵を暗号化できる
Key Cert Sign	証明書に署名できる（CA 用）
CRL Sign	CRL に署名できる（CA 用）

Leaf（サーバ証明書）
→ Digital Signature が必要（TLS 1.3 / ECDHE）
→ Key Encipherment は TLS 1.2 の RSA 鍵交換で使用
Intermediate（中間証明書）
→ KeyCertSign が必須（CA=TRUE とセット）

5.2. EKU（Extended Key Usage）＝用途の制限

証明書が どんなサービス用途に使えるか を定義します。

EKU	用途
serverAuth	Web サーバ証明書（HTTPS）
clientAuth	クライアント証明書
codeSigning	コード署名
emailProtection	S/MIME
OCSPSigning	OCSP レスポンダー

Leaf（サーバ証明書）
→ serverAuth が必須
Intermediate では通常 EKU を付けない（用途を固定しないため）

5.3. BasicConstraints（CA かどうか）

BasicConstraints	意味
CA=TRUE	この証明書は CA（中間証明書）
CA=FALSE	この証明書は Leaf（サーバ証明書）
pathLenConstraint=0	この CA の下に CA を作れない

Intermediate（中間証明書）
→ CA=TRUE が必須
Leaf（サーバ証明書）
→ CA=FALSE が必須

参考

Browsers and Certificate Validation
サーバー証明書の取得からクライアント認証までのプロセス

以上

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up