// シス担のミカタ
TLS・PKI・証明書

CT ログ（Certificate Transparency ログ） しーてぃーろぐ

Certificate Transparency証明書透明性TLS証明書認証局公開鍵基盤（PKI）Merkleツリー
CT ログについて教えて

簡単に言うとこんな感じ！

CT ログは「TLS証明書の発行記録を全部公開しておく帳簿」だよ！誰でも見られる公開台帳に証明書を登録することで、怪しい証明書が勝手に作られていないかみんなで監視できる仕組みなんだ。不正な証明書を隠せなくするための透明性の仕組みってこと！

CT ログとは

CT ログ（Certificate Transparency Log） は、認証局（CA）が発行したTLS証明書を公開の追記専用ログサーバーに記録する仕組みです。Certificate Transparency（証明書透明性） と呼ばれる標準規格の中核をなすコンポーネントで、Googleが2012年ごろに提唱し、現在はRFCとして標準化されています。

ウェブブラウザがHTTPS接続するとき、サーバーの正体を保証するのがTLS証明書です。しかし認証局が不正・誤りによって「偽の証明書」を発行してしまうと、フィッシングや中間者攻撃（MITM）に悪用される恐れがあります。CT ログは、すべての証明書発行をパブリックな台帳に記録させることで不正を早期発見できる環境を作ります。

重要な点は、CT ログが「追記専用（append-only）」であること。一度記録されたエントリは改ざんできないように Merkle ハッシュツリー という暗号技術で保護されており、ログの整合性を誰でも独立して検証できます。証明書ドメインの所有者・セキュリティ研究者・ブラウザベンダーがモニタリングツールを使って不審な証明書をいち早く検出できるようになっています。

CT ログの仕組みと構造

CT ログのエコシステムには3種類の主要プレイヤーが登場します。

プレイヤー役割
認証局（CA）証明書をCTログサーバーに提出し、SCTを取得して証明書に埋め込む
CT ログサーバー証明書を受け取り追記専用台帳に保存。SCT（署名付きタイムスタンプ）を返す
モニター／監査人ログを継続的に取得し、不審な証明書を検出・検証する

SCT（Signed Certificate Timestamp）とは

CT ログへの登録証明として発行されるのが SCT（Signed Certificate Timestamp：署名付き証明書タイムスタンプ） です。「このCTログサーバーはこの証明書を〇〇時刻に受け取りました」という電子署名入りの受領証で、TLS証明書・TLSハンドシェイク・OCSPレスポンスのいずれかに含めてブラウザへ提示されます。

現在の主要ブラウザ（Chrome・Safari など）は SCTが1つ以上存在しないとTLS接続を信頼しない ポリシーを採用しており、事実上すべての公開証明書はCTログへの登録が必須になっています。

Merkle ハッシュツリーによる改ざん検知

CT ログの整合性を守る仕組みが Merkle ツリー です。

              ルートハッシュ（Merkle Root）
             /                            \
    ハッシュ(A+B)                    ハッシュ(C+D)
     /        \                       /        \
ハッシュA  ハッシュB           ハッシュC  ハッシュD
   |           |                  |           |
証明書A      証明書B            証明書C      証明書D

新しい証明書を追記するたびにルートハッシュが更新され、過去エントリを1つでも変更すると全ルートが変わってしまうため、改ざんを即座に検出できます。ログサーバーは定期的に STH（Signed Tree Head：署名付きツリーヘッド） を公開し、誰でも独立して検証可能です。

歴史と背景

  • 2011年 — DigiNotarが不正ハッキングを受け、GoogleやCIAを含む500以上の偽証明書が発行される事件が発生。CA システムの脆弱性が世界的に認識される
  • 2012年 — Googleがデン・ステイプルスらとともにCertificate Transparencyを提唱。設計仕様を公開
  • 2013年 — Googleが最初のCTログサーバー（Pilot log）を公開運用開始
  • 2015年 — RFC 6962 として標準化（Certificate Transparency v1）
  • 2018年4月 — Google ChromeがすべてのEV証明書にCTログ登録を要求。EV以外も事実上必須化
  • 2021年 — RFC 9162 でCertificate Transparency v2.0が公開。より堅牢な設計に改訂
  • 現在 — Google・Cloudflare・DigiCert・Sectigo など多数の組織がCTログサーバーを運用。crt.sh などの公開検索サービスで誰でも証明書を検索可能

CT ログと関連する仕組みの全体像

CT ログはTLS/PKIのエコシステム全体の中でどう機能するかを図で整理します。

認証局（CA） 証明書を発行する機関 CT ログサーバー 公開追記専用台帳 提出 SCT 発行 署名付きタイムスタンプ （登録証明） SCT返却 Webサーバー SCT入り証明書を提示 ブラウザ SCTを検証して接続可否判断 提示 モニター／監査人 ログを巡回して 不審証明書を検出 公開検索サービス（例: crt.sh） 誰でもドメイン名で証明書を検索・監視できる公開インターフェース

主要なCTログ運用組織

ログ名運営特徴
Google Xenon / ArgonGoogle最初期から運用。Chromeポリシーの基準ログ
Cloudflare NimbusCloudflare大規模・高可用性
DigiCert LogDigiCertCA自身が運用するログ
Sectigo Sabre / MammothSectigo多数のCAをカバー

CT ログ vs 従来の証明書管理

観点従来の PKI のみCT ログあり
不正証明書の発見被害が出るまで気づきにくい発行直後に検索・検出可能
透明性CAを信頼するしかない第三者監査が常時可能
改ざん耐性ログなしMerkleツリーで保証
ドメイン所有者の監視手動・困難crt.sh 等で自動監視が容易

関連する規格・RFC

規格・RFC番号内容
RFC 6962Certificate Transparency v1（2013年標準化）
RFC 9162Certificate Transparency v2.0（2021年。v1の改訂版）
RFC 5280X.509証明書・CRL プロファイル（CT ログが記録する証明書フォーマット）
RFC 8446TLS 1.3（CTログがカバーするプロトコル）

関連用語