CT（証明書の透明性）とは
CT（証明書の透明性）とは全ての証明書について信用がおける検証可能な記録をCTログとして残すことで証明書の透明性を確保し、仮に悪意のある活動があった場合発見できることを目的としています。
CTが提唱された背景には2011年にオランダのCA DigiNotar社のセキュリティが破られ、google.com や microsoft.com のようなメジャーなドメインを含む大量の偽証明書が発行されてしまい、実際に悪用される、というインシデントが発生したことがあります。
CTはGoogle社によって設計されたもので、2015年、Chrome41で2015年に発行されたEV証明書に対してCTを要求開始しました。CTログはGoogle社によって3つ（Pilot Aviator, Rocketeerという名前）地理的に分散して配置されました。その後、2018年にはChromeが新規発行されるすべての証明書にCTを要求するようになり、おってアップル社も同様にすべての証明書にCTを要求するようになりました。マイクロソフト社もEdgeでCTに対応しています。Firefoxは原書執筆時点ではCTの設計を批判し、CT未対応でした。2021年時点でCTログの運営はCloudFlare, DigiCert, Google, Let's Encrypt, Sectgo, Trust Asiaの6社が参画しています。
調べたところでは2026年時点ではMozillaもmozilla trusted logsというGoogle社とは別なCTログを運用しているようです？firefox自体はCTログは必須ではないようですが、CAにCTログ利用は推奨しているようです。
2026年現在のCTログの悪用
こちらの記事はわかりやすいと思いますのでご紹介します。
外部からアクセス可能なhttpsサイトはドメイン設定後「即」攻撃にさらされる件
一言で言うとCTログは誰でもアクセス可能なため本来伏せておきたいサイト情報などもCTログを検索すると即バレしてしまう、というものです。
CTに関するあれこれ
・CTに未対応だとCTを要求するクライアントで証明書が機能しない
・CTが要求されないためCTログに登録されていない証明書をCAが発行する、というケースもある
・一般のユーザーにとってCTは、自社サイトについて、発行されるはずがない証明書が発行されていないか確認できる、という点です。大規模なユーザー（企業）ほど自社サイトの証明書発行を監視できるのは有益です。
CTが機能するしくみ
「CTを理解するには脅威モデルの観点で個々の設計指針がどのような問題を緩和するのかを考えるのがわかりやすい」と述べています。
以下、CTの設計指針を挙げてみていきます。
パブリックな証明書はログに登録されるべきである
2011年 DigiNotar社のインシデントでは攻撃者がCAの秘密鍵を完全に破り、多数のメジャーなドメインに対する証明書を発行しました。あまりにも完全に破られたため発行された証明書の記録が何も残されていませんでした。
この当時、CAによる証明書の発行を監視する（ログする）仕組みはありませんでした。
このインシデントケースへの対応方法として、「発行されるすべての証明書を誰でも確認できるようにすること」が考えられます。これを実現したCTログをみれば、誤って発行された証明書を発見したり、誰もが確認できない証明書を拒否したりが可能になります。
元々のPKIモデルでは証明書には単一のデジタル署名だけが含まれるものでしたが、CTモデルではその証明書が有効と認められるためには、CTログに登録してあることを証明する別な署名（タイムスタンンプ）＝ proofs of logging が必要になります。
インターネットPKIにおいては不正な証明書が見つかることは珍しくはなく、大量に見つかることもあります。このようなケースでは証明書の記録がすべて公開で残されることで不正な証明書の監視、発見が容易になります。
CTログが複数必要な理由
原書執筆時点でもCTログなしにはパブリックな証明書を発行できなくなっているため、CTログは可用性の観点でCTログを運用する組織は複数必要です。理想を言えばCTログの運用者とソフトウェアに一定の多様性があり、堅牢で可塑性のあるプラットフォームが複数の組織のコスト負担で運用される状態が必要、と述べています。
CTログに多様性が必要な理由
CTログは単に複数あれば良い、ということではありません。そこにどのような証明書が登録されているかのレベルで多様性が求められます。証明書を発行したCA自身が「その証明書がCTログに登録されていること」を保証する、ということでは何らかの技術的な制御手段がない限り意味がないと言えます。（原書執筆時点がまさにこの状況だと述べています。）
CTログに多様性が必要な理由をいくつか具体的にあげると以下のようになります。
CTログ運用の観点
証明書を発行するシステムとログするシステムはアーキテクチャー上でも別々になっていることが望まれます。しかも証明書の発行は極めて重要、かつ時間の影響を受ける機能なので、可用性を高めるためにCTログの運用者とインフラに対して選択肢があるべきと言えます。
また1つの証明書が（理想的にはアーキテクチャーや運営組織が異なるの）複数のCTログに登録されるようになっていればすべてのCTログがおかしい、ということは考えにくいためセキュリティが向上します。
また、証明書の有効期間中にもかかわらず、信頼性を損なったCTログが発生したとしてもCTログの冗長性があれば長期的な視点でも安定性が高まります。
司法管轄の観点
技術的に理想のポリシーを司法の干渉によって適用できなくなる可能性を抑えるためには、複数のCTログを複数の司法管轄（裁判管轄）に分散できることが望まれます。
CTログのソフトウェア実装の観点
すべてのCTログが同一の結果によって悪用可能にならないように、CTログのソフトウェア実装も複数あるべきです。
原書執筆の2022年頃?の状況として、上記の多様性のうち、CTログの運用だけが実現されています。具体的にはGoogle社のポリシーではGoogle社によるCTログのみ要求されますが、Apple社のポリシーでは2つの異なる運用者が要求されています。
証明書利用者（ユーザーエージェント）のポリシー
ここでいうユーザーエージェントとは主にブラウザーのことを指しています。証明書を利用するユーザーのブラウザーレベルでCTの強制を要求するかどうかのポリシーはCTの設計上は特に規定がありません。
CTに関するユーザーエージェントのポリシーは主に以下の2つの要素があります。
・信頼できるCTログ（SCTを認識できるCTログ）の一覧を管理する
・必要とするSCTの数、どのCTログのSCTを利用するかを決定する
CTログの監視
CTログは運用者の意図によって操作できてしまう範疇があるため、CTログ運用者正しく振る舞うように監視する役割が必要です。上記の意図的な運用例として原著ではCTログの公開内容を過去と現在で変えてしまう、ユーザーAに対する公開内容とユーザーBに対する公開内容を変えてしまう、などを挙げています。
CTログには年間数十億を超える証明書が登録される（原著執筆時点）ので１つ１つのログを検証するのは現実的ではありません。
このため、 マークル木（マークルツリーまたはハッシュ木（ハッシュツリー））と呼ばれる暗号技術に基づいたデータ構造を利用します。マークル木は新しい要素がそれ以前に追加された要素の上に追加されていることを暗号学的ハッシュ関数によって保証するツリー構造です。
マークルツリーはツリー構造を構築した際に、ツリー構造全体の単一のハッシュ値を計算して、これをフィンガープリントとして利用します。構成要素が変わるとハッシュ値も変化するため事後のデータ更新が監視できます。また、CTログに新しいデータが追加された際には、新しく追加されたデータだけを全て読み監視しているマークルツリーの一部を再構築してCTログのハッシュ値が構築したマークルツリーのハッシュ値と一致するか検証します。
証明書の監視
原著では、何らかの組織が自身のサイトや資産に対して発行された全ての証明書を閲覧したい、という例を証明書の監視、として紹介しています。このようなことが可能なのもCTログの運用に問題がないことを第三者組織が維持しているからだと説明しています。
## SCT（Signed Certificate Timestamps）とは
新しい証明書を発行したリアルタイムでCTログに証明書を即時登録する仕組みを構築するには色々な工夫が必要になります。そこで代わりの方法として、（CTログの運営者は？）ログを提出したCAに対してSCT（Signed Certificate Timestamps）と呼ばれるproof of logging を発行します。SCTは証明書を期限内に公開する約束に対する署名、といえます。
また、この期限のことを、MMD（Maximum Merge Delay）といい全てのCTログについてMMDは24時間です。
参考）digicert : 認証局はどのようにCTログを提供するのですか？
証明書がCTログに登録されているか？を確認する方法
証明書がCTログに登録されているか、発行済みの全ての証明書を検索する方法は複雑さ、パフォーマンスなどの観点で現実的ではありません。現実的なのはクライアントが証明書を利用する時点でSCTを利用する方法です。具体的には、
方法1. 証明書にSCTを埋め込む
方法2. TLSプロトコルを拡張する
方法3. OCSPに必要なデータを埋め込む
方法2.はすべてのサーバーでソフトウェア更新が必要になるため現実的ではありません。方法3.もOCSPによる失効確認があまり浸透していない現状では実際的ではないとしています。OCSPステープリングを使う方法もありますがこれもサーバー側のソフトウェア更新が必要になります。
消去法的に利用可能なのが方法1.証明書にSCTを埋め込むこと となります。
ところでSCTはCAが証明書を発行した結果取得できるものなので、証明書なしにはSCTは入手できません。
この問題を解決するために プレ証明書（precertificate) を利用します。
プレ証明書をCTログに登録してSCT署名をうけとり、これを証明書に埋め込むことでCTログに登録された信頼のおける証明書であることを識別できます。プレ証明書と実際にユーザーが使用する証明書に含まれる情報は同一のものでなければなりません。（プレ証明書はコンプライアンス的にも証明書と同一とみなされます。）
監査 auditing
SCTを使用してCTログの正しさを証明できるのは、証明書が指定された時間までにCTログに記録されるか、にとどまります。
これだけですとたとえば、
・攻撃の有無
・CAや複数のCTログが共謀でステルス証明書を発行したか
などの監査はできないことになります。CTでは上記のような正しくない状態を検出する事を監査（auditing）と呼びます。
監査を実際に行う場合、SCTがCTログに含まれることを継続的に検証する事で確認できます。この検証にはマークルツリーから導出されるinclusion proofと呼ばれるハッシュ値を利用でき、原理的にはMMDを過ぎている証明書を直接探すことが可能です。
しかし上記では規模の拡大に対応できないため、監査をサービスとして提供する専用ネットワークが利用されます。
CTログを調べるツール、APIなど
色々あるようです、また詳しく調べたいと思いますがいったんメモ程度に有用なサイトから引用いたします。
引用元：SSL証明書監査ログの活用：証明書透明性（CT Log）の読み解き方
Chromeで調べる
Chromeで任意のWebサイトを開き、アドレスバーの鍵アイコンをクリック → 「接続が安全」→「証明書（有効）」を開く
「CTログ」や「SCT情報」の欄でログサーバー名とタイムスタンプを確認できます。
ツールで調べる
特定のドメインを指定して検索できます。
crt.sh（Certificate Search）
Google Transparency Report
Censys
以上の他に原書では、Google社のTrillianも紹介しています。
APIで自動的に監視する仕組みを構築する
Google Certificate Transparency API などのAPIでCTログを定期的に確認する仕組みを構築できます。
CTログの監視サービス
certspotter：個別監視サービスの代表格
crt.sh ： 公開検索インターフェース（上掲、無償）
Google Argon ： CT log そのものの提供者、無償API提供
Cloudflare Merkle Town ： CT log の可視化ダッシュボード 無償
Sectigo Subscribe ： 認証局付随の CT 監視
複数のCTログを比較する
複数のCTログが同一か比較・表示するモニターとしてゴシッピング（gossiping）と呼ばれる仕組みが検討中、と原書に一言だけ記載があります。あまり丁寧に調べていませんが、複数のCTログを比較する方法やサービスなどは色々あるようです。
CTの実装における問題点
原書執筆時点で複数のCTポリシーが存在していることを挙げています。具体的にはGoogle社とApple社のポリシーです。両社は当初類似性が高いものでしたが、2021年にGoogle社がGoogle社運営のCTログから得たSCTを証明書に埋め込むことを要求しはじめ、組織・企業によってはGoogle社ポリシーを適用する事が難しいという問題が出てきました。SCTの監査は2021年後半に始まったばかりの仕組みでしたが、上記の要求でSCTを普及させようとした、と書かれています。一方でこの方法は全世界の証明書発行に関してGoogle社を（SPOF単一障害点）にするものである、という指摘もありました。（当時、Google社はSCTの監査が順調に普及すればGoogleのCTログを1つ含めるというポリシーを取り下げる、とも言っています。）
対してApple社の2021年時点でのポリシーではCTログの運用者に関する多様性を認めています。
原書執筆時点では、有効期間が180日以内の証明書については2つのSCTが必要、それ以外（180日以上の有効期間）の場合は3つのSCTが必要、かつ、少なくとも2つのCTログの運用者からのものである必要があり、2つのうち1つはGoogle社のCTログが必要、となっていました。