証明書透明性(Certificate Transparency, CT)

1. 概要

A. 定義

証明書透明性(Certificate Transparency, CT) とは、公的に信頼されるすべての TLS サーバ証明書の発行事実を、誰もが閲覧でき事後に削除・改ざんが不可能な公開追記専用ログ(public append-only log) に記録させることで、認証局(CA)の誤発行(mis-issuance) を事実上隠せなくする公開監視体系である。CT は 2013 年に RFC 6962 として標準化され、2021 年 12 月に RFC 9162(CT 2.0)として改定され、中核となる基盤データ構造はマークルハッシュツリー(Merkle Hash Tree) である。

従来の PKI は「ルートストアに含まれる CA が発行した証明書なら信頼する」という前提の上に成り立っている。しかしこの信頼は、CA が常に正しく振る舞うという前提に全面的に依存する。たった一つの CA でも侵害されたり、過失・悪意で特定ドメイン(例:google.com)に対する証明書を所有者の同意なく発行すれば、攻撃者はその証明書で正規サーバを完璧に偽装できる。問題は、こうした誤発行が発行時点ではドメイン所有者ですら気づけないという点である。CT は「信頼を取り除く」のではなく、すべての発行を公開記録として強制し、誤発行を事後にでも必ず露見させることで、CA 生態系に検証可能な説明責任(verifiable accountability) を付与する。

CT の設計哲学は「予防ではなく検知(detection, not prevention)」と要約される。CT 自体が誤発行を防ぐわけではない。むしろどの証明書が発行されたかを全世界が同一に観察できるようにし、誤発行が速やかに発見され失効・是正されるようにする。これはセキュリティを「完璧な城壁」ではなく「透明な監査ログ」として捉える転換であり、ブロックチェーンと同様に改ざん検知性(tamper-evidence) を暗号学的に証明する点で、技術士の観点における信頼モデル設計の事例として重要である。

B. 登場背景と必要性

CT の直接的な契機は、2011 年のオランダの CA である DigiNotar 侵害事件である。攻撃者は DigiNotar を掌握し、*.google.com を含む 500 枚余りの不正証明書を発行し、これを用いてイランの利用者数十万人の Gmail トラフィックを中間者(MITM)で傍受したと伝えられている。この事件で最も衝撃的だったのは、不正発行が数週間にわたって検知されなかったという事実である。たった一か所の CA の失敗が全ウェブの信頼を崩し得ること、そして被害ドメインの所有者(Google)ですら自らの名で発行された偽の証明書の存在を即座に知り得ないという構造的空白が露呈した。

その後 Google のエンジニアが主導し、「すべての発行を公開ログに残し、ブラウザがログに記録されていない証明書を拒否すれば誤発行を隠せない」という考えを RFC 6962 として具体化した。ここに 2015 年の Symantec の反復的誤発行(テスト目的で google.com 等に対する証明書を無断発行)が CT ログを通じて露見したことで、CT の実効性が立証された。この事件は結局 Symantec の CA 事業の信頼撤回(distrust)と DigiCert による買収につながり、CT が CA ガバナンスを実質的に規律する装置であることを印象づけた。

その結果 Chrome は 2018 年 4 月以降に発行されたすべての公的信頼証明書に対し CT 準拠を強制し始め、Apple も同様の方針を施行した。すなわち今日の CT は「選択的なベストプラクティス」ではなく、公開ウェブ PKI に参加するための事実上の必須要件である。技術士の観点から CT は、TLS・PKI というインターネット信頼の根に監視・透明性の層を重ねたものであり、一つの標準変更が全世界の CA・ブラウザ・サーバ運用に即座に波及する生態系ガバナンス問題として理解すべきである。

2. CT 生態系の構成要素と全体構造

CT は単一のシステムではなく、互いを牽制する複数の役割者による分散監視生態系である。以下の全体構造図は、CA の証明書提出からログ記録、ブラウザ検証、そしてモニタ・監査者による常時監視までの関係を示している。いずれの主体も単独で信頼を独占せず、互いの行為を相互検証するという点が核心である。

flowchart TD
  CA["認証局(CA)"]
  LOG["CT ログサーバ(追記専用・Merkle Tree)"]
  SERVER["対象ウェブサーバ(TLS 終端)"]
  BROWSER["ブラウザ(検証者・Relying Party)"]
  MONITOR["モニタ(ドメイン所有者・セキュリティ企業)"]
  AUDITOR["監査者(ログ一貫性検証)"]
  CA -->|"① プリ証明書を提出"| LOG
  LOG -->|"② SCT(記録の約束)を発行"| CA
  CA -->|"③ SCT を内蔵した証明書を発行"| SERVER
  SERVER -->|"④ TLS ハンドシェイク + SCT 提示"| BROWSER
  BROWSER -->|"⑤ SCT 署名・ポリシー検証"| BROWSER
  LOG -->|"全ログを照会"| MONITOR
  MONITOR -->|"自ドメインの誤発行を検知・警報"| MONITOR
  AUDITOR -->|"包含・一貫性証明を要求"| LOG
  BROWSER -.->|"SCT 監査の協力"| AUDITOR
  style CA fill:#e8f0fe,stroke:#2f6fed,stroke-width:1px
  style LOG fill:#eafbea,stroke:#2f9e44,stroke-width:1px
  style BROWSER fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px
  style MONITOR fill:#f3e8fe,stroke:#8f2fed,stroke-width:1px

A. ログ(Log)

CT ログは、提出された証明書を時系列順に追記するだけの追記専用(append-only)サーバであり、内部的にマークルハッシュツリーを維持する。ログは削除・修正・並べ替えが不可能になるよう設計され、自らが記録した全状態を STH(Signed Tree Head, 署名されたツリーヘッド) として署名し公表する。ログ運営者は Google(Argon・Xenon 系)、Cloudflare(Nimbus)、DigiCert、Sectigo、Let's Encrypt(Oak)等であり、信頼性確保のため複数の独立運営主体が多数のログを運営する。ログは通常 1 年単位のシャード(shard) として分割運営され、特定年に満了する証明書のみを受け付ける形で大きさを管理する。

ログの核心的な約束の一つが MMD(Maximum Merge Delay, 最大マージ遅延) であり、通常 24 時間である。ログは SCT を発行した時点から MMD 以内にその証明書を実際にマークルツリーへマージ(包含)しなければならない。この約束のおかげで SCT は「今まさにツリーに入っている」ではなく「MMD 以内に必ず入る」という記録の約束(promise) として機能し、発行遅延なしに即座に証明書を使えるようにする。例えばログが SCT だけを発行し実際のマージを怠れば、監査者が包含証明を要求した際に証明に失敗するため、ログの不正が露見する。

B. SCT と CA・サーバ

SCT(Signed Certificate Timestamp) は、ログが「この証明書を受け付け、MMD 以内に記録する」と署名した領収書である。CA は発行前にプリ証明書(precertificate) をログに提出して SCT を受け取り、これらの SCT を最終証明書に収めて発行する。プリ証明書は最終証明書と内容が同じだがポイズン拡張(poison extension) が入っており、それ自体では TLS に使えない「記録用の写し」である。こうすれば「証明書の中に SCT を入れなければならないが、SCT を受け取るには証明書を先にログへ入れなければならない」という循環依存をきれいに解消できる。

C. モニタ(Monitor)と監査者(Auditor)

モニタは、ログ全体をダウンロードして「自分が関心を持つドメインに対し自分の知らない証明書が発行されていないか」を常時監視する役割者である。大手サービス企業は自社ドメインに対するすべての発行を監視し、crt.sh(Sectigo)、Censys、Cloudflare 等は誰もが検索できる公開モニタを提供する。監査者は主にブラウザに内蔵された形で、ログが提示した STH と証明を受け取り、ログが嘘をついていないか(二人の利用者に互いに異なるログを見せる「分岐(split-view)」攻撃をしていないか)を検証する。モニタは「CA の正直さ」を、監査者は「ログの正直さ」を監視するという点で責任が分離される。

モニタと監査者の分離は、CT が単一の信頼の失敗点(single point of trust)を置かないという原則の具体的実装である。もし監視の役割が一つの主体に集中すれば、その主体が侵害・買収された際に全体の透明性が崩れる。そこで CT は多数の独立モニタと、ブラウザという数十億台の分散監査者を同時に運営する。どの CA が誤発行しても、いずれか一つのモニタが起きていれば摘発され、どのログが嘘をついても、互いに STH を交換する監査者が一つでも正直なら矛盾が露見する。このように「多数のうち一つでも正直なら全体が守られる」という N 分の 1 信頼モデルが CT の堅牢性の数学的な礎である。

D. ログの信頼性確保要件

ログが生態系の核心である以上、ブラウザはログを誰にでも運営させるのではなく厳格な包含基準を適用する。ログは一定の可用性(SLA)、明確な運営ポリシー、独立した運営主体、そして上限 MMD の遵守等を立証してこそ公開信頼ログ一覧に含まれる。またブラウザは一つの運営者が全 SCT を独占できないよう、互いに異なる運営者のログから SCT を受け取るよう要求する(例:一つは特定ベンダ、もう一つはそれと独立したベンダ)。これは特定のログ運営者が事業を畳んだり信頼を失っても、すでに発行された証明書が一度に無効化されないようにする運用多様性(operational diversity) 確保の装置である。実際、特定のログが規定違反や障害で「不信(distrust)」処理された前例があり、この際その単一のログに依存していた証明書は再発行の圧力を受けた。ログ運用はすなわち生態系の信頼インフラ運用であるという点で、技術士の観点における可用性・ガバナンス設計の対象となる。

3. 動作原理:ログ記録・SCT・暗号学的証明

CT の信頼はマークルツリーの二つの証明、すなわち包含証明(inclusion proof) と一貫性証明(consistency proof) から生まれる。以下の詳細フロー図は、プリ証明書の提出→SCT 発行→証明書配布→ブラウザ検証→モニタ・監査の全過程を順に示している。

sequenceDiagram
  participant CA as CA
  participant Log as CT ログ
  participant Srv as ウェブサーバ
  participant Br as ブラウザ
  participant Mon as モニタ
  CA->>Log: プリ証明書を提出(poison 拡張)
  Log-->>CA: 署名した SCT を返却(MMD 以内のマージ約束)
  CA->>Srv: SCT を内蔵した証明書を発行
  Note over Log: MMD(24h) 以内に Merkle Tree へマージ
  Br->>Srv: TLS ハンドシェイク要求
  Srv-->>Br: 証明書 + SCT を提示
  Br->>Br: SCT 署名・個数・ログポリシーを検証
  Mon->>Log: 全ログを定期的に照会
  Mon-->>Mon: 自ドメインの誤発行を検知時に警報

A. マークルツリーと包含証明

ログのすべての項目はマークルツリーの葉(leaf)にハッシュされて入り、葉を二つずつ束ねてハッシュする過程を繰り返してただ一つのルートハッシュ(Merkle Tree Hash) へ収束する。包含証明とは「特定の証明書がこのルートに実際に含まれている」を証明するもので、ツリー全体ではなく経路上の兄弟ノードのハッシュ(log₂N 個)だけを提示すれば検証者がルートを再計算して確認できる。例えば 100 万件(2²⁰)規模のログでも約 20 個のハッシュだけで包含を証明でき、大規模なログでも検証コストが対数的にしか増加しない。

この対数的効率性は、CT が数十億枚規模に拡張できた決定的な理由である。例えば全世界の有効証明書が数億枚に達し、短命証明書化で発行頻度が急増する状況で、もし包含証明がツリー全体の大きさに比例していたなら、検証は事実上不可能だっただろう。マークルツリーは「全体を全部見なくても全体の一片が全体に属することを証明」させてくれ、この性質はブロックチェーン・Git・分散バックアップ等、改ざん検知が必要な他分野でも同様に活用される。CT の包含証明は結局 [[merkle-tree]] が提供する完全性検証の原理を「証明書発行の透明性」という具体的な問題に適用した事例として理解できる。

B. 一貫性証明と分岐攻撃防御

一貫性証明は「過去のツリー(大きさ m)が現在のツリー(大きさ n, n>m)に接頭(prefix)としてそのまま含まれている」を証明する。これはログが過去の記録を削除・修正せず、ひたすら追記だけしたことを暗号学的に保証する。もしログが特定の監査者には A というツリーを、別の監査者には A と矛盾する B というツリーを見せる分岐攻撃(split-view) を試みれば、STH を相互共有する「ゴシップ(gossip)プロトコル」を通じて二つの STH が互いに一貫性証明を作れないことが露見し、不正が摘発される。すなわちログですら信頼の特権を持たず、数学的に正直を強制される。

C. SCT の伝達方式

ブラウザは通常二つ以上の互いに異なるログから発行された SCT を要求し(証明書の有効期間により要求個数が変わる)、これは特定の一つのログに問題があっても生態系が揺らがないようにする多様性要件である。SCT をサーバがブラウザに伝達する経路は三つあり、それぞれ長短が明確である。

伝達方式	方法	長所	短所
X.509v3 拡張内蔵	証明書自体に SCT を含める(プリ証明書ベース)	サーバ・CA 設定変更不要、最も広く使用	発行後に SCT を変更不可
TLS 拡張(ALPN/SCT 拡張)	ハンドシェイク時にサーバが SCT を伝達	発行後も SCT の交換・追加が柔軟	サーバ設定が複雑、対応が限定的
OCSP Stapling	OCSP 応答に SCT を載せて伝達	既存の Stapling インフラを再活用	OCSP 自体が縮小傾向

実務的には全世界の証明書の大多数は X.509v3 拡張内蔵方式を使う。CA が発行過程で自動的に SCT を入れてくれるため、サーバ管理者が別途の設定をする必要がなく、Let's Encrypt のような自動化 CA では特に既定値として動作する。この単純さが CT の全面的な普及を可能にした実用的な核心である。

4. 従来の PKI 信頼モデルとの比較および事例

CT を従来の失効(CRL・OCSP)ベースの信頼と比較すると、その性格の違いが明確になる。失効が「すでに信頼した証明書を事後に撤回する」事後対応なら、CT は「発行事実そのものを皆が見られるようにする」発行段階の透明化である。両者は代替財ではなく相互補完財である。CT で誤発行を発見すれば、その証明書を失効(revocation)で実際に無効化する形で連結される。

区分	従来の PKI(失効ベース)	証明書透明性(CT)
信頼前提	CA の善意・正確性を信頼	CA を信頼しつつ公開検証で牽制
焦点	事後の信頼撤回(失効)	発行の公開・検知
改ざん防止	署名チェーン	マークルツリーベースの暗号学的証明
誤発行の可視性	所有者も知り得ないことがある	モニタが即座に検知可能
強制手段	ルートストア包含ポリシー	ブラウザの SCT 要求(非準拠なら遮断)

違いが生じる根本的な理由は、信頼の所在(locus) が異なるためである。失効モデルは信頼を CA に置き、問題が生じれば取り戻す一方、CT は信頼を「公開観察可能性」という生態系属性に分散する。実務的な含意として、CT がある環境ではドメイン所有者が CT モニタリングを通じて自らのセキュリティを CA に全面委任せず、直接確認できる。例えばある企業が自社ドメインに対し発行されたことのないワイルドカード証明書が CT ログに上がったのをモニタで発見すれば、これは内部流出や CA 誤発行の早期警報となる。

具体的な事例として、2017 年に Google は Symantec が CT ログ外部でテスト証明書を発行してきた状況を CT を通じて追跡・確認し、これが約 3 万枚以上の証明書の信頼に影響する大規模な信頼撤回の決定につながった。また Facebook は CT モニタリングを自動化し、自社ドメインに対する予期せぬ証明書発行を数分以内に検知する内部警報体系を運用していると公開したことがある。このように CT は理論的な装置ではなく、実際の大手サービスの常時セキュリティ運用に深く統合されている。

興味深い点は、CT が攻撃者だけでなく防御者の偵察ツールとしても使われるという両面性である。セキュリティ研究者・レッドチームは crt.sh 等で特定組織の CT 記録を検索し、外部に露出した下位ドメイン・内部システム名を収集する資産探索(asset discovery) に活用する。逆にブルーチームは同じデータで「シャドー IT」や満了間近の証明書を先制的に識別する。同じ透明性が攻撃・防御双方の可視性を同時に高めるという事実は、セキュリティ設計が常に「我々に開いた窓は相手にも開く」という観点を要求することを示す好例である。

5. 深化:Static CT API(Sunlight・Tiled Log)と CT 2.0 の動向

従来の RFC 6962 ログは運用コストと複雑性が高かった。ログが直接状態を照会型 API でサービスしなければならず、可用性・拡張性の負担が運営者に集中した。これを解消するため、2024 年前後に Static CT API(静的 CT API, 旧名 Sunlight API) が登場した。この方式はログをタイル(tile)と呼ばれる平面ファイルの集合として表現し、CDN・オブジェクトストレージ(S3 等)から静的ファイルのように配布する。タイルは 256 項目単位で構成され、検証者は動的 API の代わりに静的ファイルをダウンロードしてツリーを再構成する。代表的な実装が Filippo Valsorda の Sunlight であり、Let's Encrypt は 2024〜2025 年にかけてこれをプロダクションに導入し、その運用経験を公開した。

Static CT API の設計意義は、運用コストの急減と可用性の向上にある。動的サーバの代わりに静的ファイル配布モデルを選ぶことで、ログ運営者はデータベース負荷と照会殺到のリスクから解放され、CDN のキャッシュ・可用性をそのまま活用する。主要ブラウザ(Chrome 等)も 2025 年前後に Static CT API ログを公開信頼ログの候補として受け入れるポリシー変更を反映した。ただしこの方式は静的ログが要求する leaf_index 拡張を SCT に含めるなど詳細規格が異なるため、ブラウザポリシーは当面 RFC 6962 ログと静的ログを並行認定する移行期を経ている。(詳細規格・ポリシー数値は変動可能性があり、一般化して記述する。)

標準の側面では RFC 9162 が定義する CT 2.0 があるが、2026 年現在の主要ブラウザの実際の実装は依然として RFC 6962 系が中心である。CT 2.0 は SCT 構造の改善、包含証明ベースの検証強化等を含んでおり、長期的には移行が予想されるが、既存生態系の互換性のため移行は漸進的である。

ブラウザ強制の実際の効果も深化学習のポイントである。Chrome は CT 非準拠の証明書に対し「安全な接続ではない」エラーを出し接続を事実上遮断するため、CA が CT を飛ばす経済的誘因が消えた。この「ブラウザ主導の強制」は、標準文書(RFC)の勧告だけでは達成しにくい生態系の転換を、市場支配的なクライアントのポリシーで短期間に実現した事例である。ただしこれは少数のブラウザベンダが事実上の規範制定者になる中央集中的なガバナンスへの偏りという両義的側面も持ち、これに対応して CA/Browser Forum・IETF のような多者協議体が均衡錘の役割を果たす。

6. 考慮事項および示唆点(技術士の観点)

• 適用戦略 — CT モニタリングの内在化:CT はもはや「ブラウザが勝手にやること」にとどまらない。ドメインを保有するすべての組織は crt.sh・Censys または商用モニタを通じて自社ドメインに対する発行を常時監視し、未認可の発行をセキュリティ管制(SOC)・事故対応(IR)プロセスに連動させるべきである。これは供給網・内部流出の早期警報チャネルとして機能する。

• トレードオフ — 透明性とプライバシー:CT はすべての公開証明書を露出するため、組織がまだ公開していない内部サービスドメイン(subdomain)が CT ログを通じて外部に露呈する情報露出リスクがある。これに対する緩和策としてワイルドカード証明書の使用や、発行前のドメイン命名戦略の策定が必要である。透明性の利得とドメイン機密性の衝突を設計段階で意識せねばならない。

• 展望 — 短命証明書・自動化との結合:証明書の有効期間が 47 日水準に短縮される流れ(CA/Browser Forum)の中で発行頻度が急増すると、CT ログの処理量も急増する。Static CT API への転換はこの拡張性圧力に対する生態系の応答であり、組織は ACME ベースの自動発行・更新と CT が自動的にかみ合って回るパイプラインを前提にインフラを設計すべきである。

• 連携技術 — PKI・失効・供給網セキュリティの統合観点:CT は単独の技術ではなく、PKI、証明書失効(CRL・OCSP)、CAA レコード(DNS ベースの発行制限)、そして広くはソフトウェア供給網の透明性(SBOM)の流れと同じ「検証可能な透明性」系に属する。技術士は CT を個別のセキュリティ統制ではなく、信頼を暗号学的証明と公開監視で再構成する大きな設計原則の一実装として理解し、組織の全般的な信頼・ガバナンス体系に位置づけるべきである。

• ガバナンス — 標準・ブラウザポリシー追跡の常時化:CT 準拠要件(要求 SCT 個数、認定ログ一覧、静的ログ受容の可否)はブラウザ・CA/Browser Forum のポリシーにより変わる。一度設定して終わるものではなく、ポリシー変更を常時追跡して証明書運用体系に先制反映する継続的なガバナンス活動が必要である。

参考資料

• RFC 9162, Certificate Transparency Version 2.0: https://www.ietf.org/rfc/rfc9162.html
• Static CT API (C2SP): https://github.com/C2SP/C2SP/blob/main/static-ct-api.md
• Sunlight CT Log: https://sunlight.dev/
• Reflections on a Year of Sunlight (Let's Encrypt): https://letsencrypt.org/2025/06/11/reflections-on-a-year-of-sunlight

---

一言まとめ: 証明書透明性(CT)はすべての公開 TLS 証明書の発行をマークルツリーベースの公開追記専用ログに記録させ、CA の誤発行を事後に必ず露見させる「検知中心」の信頼体系であり、SCT・包含/一貫性証明・モニタ・監査者の分散監視で動作し、Static CT API で拡張性・運用性を高めている。