証明書透明性（Certificate Transparency）の仕組み

なぜ「正しく署名された証明書」だけでは足りないのか

TLS のハンドシェイクでサーバー証明書のチェーンと署名を検証すれば、その証明書が信頼された CA（認証局）によって発行された本物だと確認できます。しかしここには見落としやすい前提があります——「信頼された CA が発行した」ことと「その CA が正しく発行した」ことは別物 だという点です。

CA が攻撃者に乗っ取られたり、内部不正や手続きミスで example.com の証明書を所有者でない第三者に発行してしまえば、その証明書はチェーン検証を完璧に通過します。クライアントには本物と区別がつきません。実際 2011 年の DigiNotar 事件では、不正発行された Google 向け証明書が中間者攻撃に使われました。問題は、こうした誤発行が 当事者の知らないところで起きうる ことです。ドメイン所有者は、自分のドメインに対して勝手に証明書が発行されても、それを知る手段を持っていませんでした。

証明書透明性（Certificate Transparency, CT、RFC 6962）はこの盲点を埋めます。発想は監視や暗号の強化ではなく 可視化 です。すべての証明書を 誰でも閲覧・検証できる公開ログ に記録させ、「こっそり発行する」を不可能にします。不正発行そのものを防ぐのではなく、起きたら必ず後から気づける ようにするのが CT の役割です。

公開ログ：誰でも読めて、誰も書き換えられない記録

CT の中核は CT ログ です。これは CA とは独立した運用者（Google、Cloudflare、Let's Encrypt など）が運営する、証明書を時系列に追記していく公開サーバーです。重要な性質は二つあります。

ひとつは 追記専用（append-only） であること。ログには新しい証明書を末尾に足すことしかできず、過去のエントリを書き換えたり削除したりできない。もしログ運用者が悪意を持って不正発行の記録をこっそり消そうとしても、それが検出できなければ意味がありません。

もうひとつは 公開性 です。誰でもログの全エントリを取得でき、誰でもその完全性を検証できます。これにより、ドメイン所有者は自分のドメインに対する全発行を後から監査でき、研究者やブラウザベンダはログ全体の振る舞いを監視できます。

問題は「追記専用であること」をどう 暗号学的に証明 するかです。「消していません」という運用者の言葉を信じるのでは、CA を盲信していた元の問題に逆戻りします。ここで Merkle ハッシュ木が効いてきます。

Merkle 木が追記専用性を保証する

CT ログは全エントリを Merkle ハッシュ木 として構成します。葉（リーフ）が個々の証明書エントリのハッシュで、内部ノードは「左の子と右の子のハッシュを連結して再ハッシュした値」、頂点が ルートハッシュ（Merkle Tree Hash, MTH） です。ルートはログ全体を 1 個のハッシュ値に要約します。

            ROOT = H(H01 || H23)
           /                    \
      H01 = H(H0||H1)      H23 = H(H2||H3)
       /        \            /        \
   H0=H(c0)  H1=H(c1)    H2=H(c2)  H3=H(c3)
     |          |           |          |
   cert0      cert1       cert2      cert3   ← 証明書エントリ（葉）

ハッシュ関数の衝突困難性により、葉を 1 個でも改ざんすればルートハッシュが変わります。逆に言えば、ルートハッシュが同じなら木の中身も同じ。ログ運用者は一定間隔（最大マージ遅延, MMD 以内）で最新のルートに署名し、STH（Signed Tree Head） として公開します。STH にはツリーサイズ（葉の総数）・タイムスタンプ・ルートハッシュと運用者の署名が含まれます。

この構造の上に、二種類の効率的な証明が乗ります。

包含証明（inclusion / audit proof）：「証明書 X は、このルートハッシュを持つ木の中に確かに含まれる」ことを証明します。X からルートまでの経路にある 兄弟ノードのハッシュだけ を渡せば、検証側はそれらを順に連結・再ハッシュしてルートを再計算し、署名済み STH と一致するか確かめられます。木の高さは葉数 N に対して log2(N) なので、数百万件のログでも証明は数十ハッシュ分で済みます。

整合性証明（consistency proof）：「サイズ M の古い木は、サイズ N（N ≥ M）の新しい木の 接頭辞（prefix） である」ことを証明します。これが追記専用性の核心です。新しい木が古い木に エントリを末尾追加しただけ で作られた——途中を書き換えたり消したりしていない——ことを、やはり少数のノードハッシュだけで暗号学的に示せます。もしログ運用者が過去を改ざんすれば、新旧 2 つの STH の間で整合性証明が成立しなくなり、改ざんが露見 します。

SCT：ログに登録した「領収書」をどう運ぶか

ログに証明書を登録すると、ログは SCT（Signed Certificate Timestamp, 署名付き証明書タイムスタンプ） を返します。SCT は「この証明書を時刻 T までに（最大マージ遅延 MMD 以内に）ログへ組み込むと約束する」という、ログ運用者の署名付きの約束手形 です。クライアントは証明書とともに SCT を受け取り、ログの公開鍵で SCT の署名を検証することで、「この証明書はちゃんと公開ログに載っている（はず）」と確認できます。

クライアントは通常、1 つの証明書につき 複数の独立したログ由来の SCT を要求します。単一ログの故障や不正に依存しないためです。SCT をクライアントへ届ける経路は 3 つあります。

プリ証明書（precertificate）という工夫

SCT を証明書の拡張に埋め込むには、循環が生じます——SCT を得るにはログ登録が要るが、登録する証明書の中に SCT を入れたい。これを解くのが プリ証明書 です。CA はまず、最終証明書とほぼ同内容だが「ポイズン拡張（poison extension）」という 本番では無効なマーカー を入れた中間生成物（プリ証明書）を作ってログに登録します。ログはこれに SCT を返し、CA はその SCT を埋め込んだ 本物の証明書 を改めて発行します。ポイズン拡張のおかげでプリ証明書自体は TLS で使えず、登録専用の影武者として機能します。

1. CA: プリ証明書（poison拡張つき／本番では使用不可）を生成
2. CA -> ログ: プリ証明書を登録
3. ログ -> CA: SCT（MMD以内に組み込む約束＋署名）を返す
4. CA: SCTをX.509拡張に埋めた「本物の証明書」を発行
5. サーバー: その証明書をTLSハンドシェイクで提示
6. クライアント: SCTの署名をログ公開鍵で検証

モニタと監査人：誰が何を見張るのか

SCT と Merkle 木があっても、実際に誰かがログを読み、検証しなければ 仕組みは絵に描いた餅です。CT には監視役が二種類います。

モニタ（monitor） は、ログの 中身 を継続的に取得・走査する役です。ドメイン所有者やセキュリティ事業者が運用し、「自社ドメインに対して、自分が依頼していない証明書が発行されていないか」を監視します。不正発行や予期しない発行をここで検知し、見つかれば当該証明書の失効や CA への通報につなげます。CT が DigiNotar 型の事件に効くのは、最終的にこのモニタが「身に覚えのない発行」を 発見できる からです。

監査人（auditor） は、ログ自体が 約束を守っているか を検証する役です。主にクライアント（ブラウザ）側に組み込まれ、二つを確かめます。第一に、自分が受け取った SCT に対応するエントリが 本当にログに含まれているか（包含証明の検証）。第二に、ログが提示する新旧の STH の間で 整合性が保たれているか（整合性証明の検証）——すなわちログが過去を改ざん・削除していないか。監査人どうしが STH を gossip（伝播・突き合わせ） することで、ログが相手によって違うルートを見せる「分裂攻撃（split-view）」も検出できます。

全体像と比較

ブラウザは現在、SCT を伴わない証明書を信頼しない ポリシーを敷いています。これが CT を強制力のある仕組みにしている要石です。SCT が無ければエラーになるため、CA は発行のたびにログ登録せざるを得ず、結果として 公開 Web のほぼ全証明書がログに載る。発行が網羅的に可視化されることで、不正発行は「いつか必ず誰かに見つかる」状態に置かれます。

一段で言うと

証明書透明性は「すべての証明書を公開・追記専用のログに載せ、不正発行を後から必ず検知できるようにする」仕組みです。ログは Merkle 木で構成され、署名済みルート（STH）を起点に、包含証明で「載っていること」を、整合性証明で「過去を消していないこと」を暗号学的に立証します。ログは登録の見返りに SCT を返し、サーバーはこれを TLS ハンドシェイクで提示。クライアントは SCT の署名を確かめ、モニタ が中身を監視し、監査人 がログ自身の誠実性を検証します。CA を信頼しつつ盲信しない——その「信頼するが検証する」を Web PKI に組み込んだのが CT です（TLS 1.3 のハンドシェイク内部で SCT がどこに乗るかも併読を）。