X.509 証明書チェーン検証の内部と Certificate Transparency

チェーン検証は「構築」と「検証」の二段階

PKI の信頼は証明書チェーンで橋渡しされますが、その検証は実装上、明確に二つの工程に分かれます。混同すると障害の切り分けを誤るので、ここを押さえることが上級者への分岐点です。

1. パス構築（path building）: 提示されたリーフ証明書（サーバー証明書）から出発し、「ある証明書の Issuer（発行者名）＝次の証明書の Subject（主体者名）」となる証明書を順にたどって、端末のトラストストアにある信頼アンカーまで一本の鎖を組み立てる。
2. パス検証（path validation）: 組み上がった候補チェーンの各段を、RFC 5280 が定める規則に従って上から下へ検証する。

重要なのは、構築は「名前のつながり」だけで行い、署名の正しさは検証で確かめる点です。Issuer 名が一致しても署名が合わない（別の鍵で署名された）ことはあり得るため、両工程は独立しています。

パス構築は探索問題：単純な線形リストではない

「チェーン＝一直線」というイメージは半分正しく、半分危険です。現実には、同じ鍵ペアを持つ中間 CA が複数のルートから相互に署名されていることがあり、一つの中間証明書に対して複数の上位候補が存在します。古いルートの期限切れに備えて新ルートへのクロス署名を用意するのが典型です。

このためパス構築は、各証明書を頂点とする有向グラフ上での探索になります。素朴な実装は「最初に見つけた Issuer 一致」で進みますが、それが期限切れルートに突き当たると検証に失敗します。堅牢な実装（例: OpenSSL の新しいパスビルダーや Go の crypto/x509）は、行き止まりに当たったらバックトラックして別の候補を試す深さ優先探索を行います。「中間証明書は正しいのに特定の端末だけ失敗する」という事象の多くは、この構築段階でのアンカー選択の違いが原因です。

パス検証で各段が満たすべき条件

候補チェーンが組めたら、各証明書について次を順に確認します。一つでも破れた時点でチェーン全体が不合格です。

特に見落とされがちなのが**基本制約（Basic Constraints）**です。CA:TRUE でない証明書（＝リーフ）は、たとえその鍵で他の証明書に署名しても、検証側はその署名を「CA としての署名」と認めません。2000年代の有名な脆弱性では、この検証を怠った実装が、正規のリーフ証明書の鍵で偽の中間証明書を作る攻撃を許しました。pathLenConstraint は「この CA の下にあと何段まで中間 CA を挟めるか」を制限し、委任の連鎖が無制限に伸びるのを防ぎます。

最後に、リーフの **SAN（Subject Alternative Name）**が接続先ホスト名と一致するかを確認します。これはチェーン検証とは別の「名前照合（hostname verification）」で、ここを実装し忘れると「正しい CA が発行した別ドメインの証明書」を受け入れてしまう典型的な脆弱性になります。署名検証の数学的基盤は 署名方式 を参照してください。

失効確認：有効期間内でも信頼を取り消す

秘密鍵漏洩や誤発行に備え、有効期間内でも証明書を無効化するのが失効です。三方式の本質的な違いは「誰がいつ確認の負担を負うか」です。

OCSP の決定的な問題はソフトフェイルです。多くのブラウザは、レスポンダに到達できないと「失効していない」とみなして接続を続けます。これは可用性のための妥協ですが、攻撃者がレスポンダへの経路を遮断すれば、失効した証明書でもチェックをすり抜けられることを意味します。失効確認が「あってないようなもの」になる根本原因です。

OCSP Stapling（TLS 拡張 status_request）はこれを改善します。サーバー自身が CA から署名付き OCSP 応答を定期取得し、ハンドシェイク中に証明書と一緒に提示するため、端末は CA へ問い合わせずに失効状態を確認でき、往復遅延もプライバシー漏れも消えます。さらに OCSP Must-Staple（証明書に tls-feature 拡張を埋める）を使うと、「Staple された応答がなければ接続を拒否する」とクライアントに強制でき、ソフトフェイル問題を閉じられます。

Certificate Transparency：誤発行を「事後に必ず見える化」する

チェーン検証と失効が正しく機能しても、防げない脅威があります。正規の CA が、ドメイン所有者の知らないところで証明書を誤発行・不正発行するケースです。発行された証明書は検証上は完全に正しいため、所有者は気づけません。実際、大手 CA の運用ミスや侵害で不正証明書が出回った事件が CT 誕生の引き金でした。

Certificate Transparency（CT）は、この問題を「予防」ではなく「全件の公開と監査による事後検知」で解こうとする仕組みです。中核は追記専用（append-only）のマークル木ログです。

• ログ: 公開された複数の CT ログサーバーが、提出された全証明書を時系列で記録する。一度記録した証明書は削除・改変できない。
• SCT（Signed Certificate Timestamp）: ログは証明書を受理すると「指定時刻までにこの証明書をログへ含める」と約束する署名付き受領証を返す。ブラウザは TLS 接続時、リーフ証明書に十分な数の SCT が付いていることを要求し、なければ証明書を信頼しない（現行 Chrome / Safari は SCT 必須）。
• 監視（Monitor）: ドメイン所有者や第三者がログを継続的に走査し、「自分のドメインに対し、自分が頼んでいない証明書」が現れたら誤発行として検知できる。

SCT の運搬経路は三つあります。証明書自体への埋め込み（X.509v3 拡張）、TLS 拡張、OCSP 応答経由です。埋め込み方式は、まだ SCT を持たない段階の**プレ証明書（precertificate）**を先にログへ提出して SCT を得てから本番証明書に焼き込む、という二段構えで実現します。

マークル木が「ログの不正改ざん」を防ぐ原理

CT の信頼性は「ログ運営者自身が不正できない」ことに懸かっています。これを支えるのがハッシュ木の構造であるマークル木です。葉に各証明書のハッシュを置き、隣接ノードを連結してハッシュし上へたどると、最上位に木全体を要約した一つの値、**マークルルート（root hash）**が得られます。ログは定期的にこのルートに署名し、**STH（Signed Tree Head）**として公開します。

この構造から二種類の効率的な暗号学的証明が導けます。

• 包含証明（inclusion proof / audit path）: 「ある証明書が、署名済みのルートに確かに含まれる」ことを、根までの兄弟ノードのハッシュ列だけで示せる。N 個の葉に対し検証に必要なハッシュは log2(N) 個程度で済む。ブラウザが受け取った SCT の約束（=ログに載っている）を、自分で軽量に確認できる。
• 一貫性証明（consistency proof）: 「新しいルートは、古いルートの内容を一つも消さず・書き換えず、末尾に追記しただけで得られた」ことを証明する。これにより監査者は、ログが過去に出した証明書をこっそり差し替える**スプリットビュー（人によって違う木を見せる）**を検知できる。

つまりマークル木は、「載っていることの証明（包含）」と「過去を改ざんしていないことの証明（一貫性）」の両方を log オーダーのデータで提供し、巨大なログでも全件をダウンロードせずに健全性を監査可能にします。ハッシュの衝突困難性が破れない限り、ログ運営者は記録を後から偽れません。

まとめ

X.509 のチェーン検証は、リーフから信頼アンカーへ証明書を連結するパス構築（クロス署名により実質は探索問題）と、各段の署名・有効期間・基本制約・鍵用途・名前制約を確認するパス検証、そしてホスト名照合からなります。失効は CRL / OCSP / OCSP Stapling の三方式があり、OCSP のソフトフェイルを Must-Staple や短命証明書で補います。

これらが守るのは「提示された証明書が正しいか」ですが、Certificate Transparency は一段上の「そもそも誤発行された証明書が存在しないか」を、全件をマークル木ログへ公開し監視することで事後検知します。包含証明と一貫性証明により、ログ運営者すら記録を偽れない設計です。前提となる鍵と署名の考え方は 暗号の基礎、信頼の全体像は PKI と合わせて押さえると、TLS の検証フロー全体が一本の線でつながります。