電子証明書の透明性

電子証明書の透明性、CT（）は、の標準であり、デジタル証明書の監視・監査のためのオープンソースのソフトウェアフレームワークである。
この標準は、公に信頼される認証局が署名した証明書を逐次記録し、それを検索できる公開のログのシステムを作るというものである。
これにより、誤操作や悪意ある不正に基づく証明書の発行を効率よく検知できることを目的としている。
CTの初版は実験的のステータスであるで規定されている。バージョン2.0がで規定されている。
2021年には、TLS用の証明書でCTが必須となる予定である。
TLS用以外では引き続きCTは必須ではない。
経緯.
2011年、の認証局の再販業者が不正侵入され、別の認証局でも不正な証明書発行が行われた（2011年デジノター事件）。
これらの事件は、認証局を取り巻くエコシステムにおける欠陥への関心を呼び起こし、承認されていない証明書の発行を禁止または監視する様々な取り組みが促進されていくこととなった。
同年、これら証明書発行の問題に対抗するオープンソースのフレームワークを、Adam LangleyそしてEmilia Kasperが作り始めた。
それがCTである。
2012年コードネームSunlightとしてIETFに最初のインターネットドラフトが送信された。
利点.
デジタル証明書管理の1つの問題は、不正な証明書がウェブブラウザのベンダーに発見・報告・取り消しされるまで長期間を要することである。
CTは、ドメイン名の所有者の知らぬ間に当該ドメインに対する証明書が発行できないようにすることを支援しようというものである。
Online Certificate Status Protocol (OCSP)やと同様に、CTはサイドチャネル通信を必要としない。また、CTは信頼できる第三者を必要とせず運用できる。
欠点.
記録されたログを調べることで、関係者のみで利用するFQDN（簡単に言うとサーバ名）が、外部にさらされてしまう。
構成について.
構成について
CTログ.
CTログは証明書・プレ証明書を記録していく台帳である。
データ構造としてマークル木が用いられる。
証明書・プレ証明書の登録をCTログに要求すると、CTログはその証に署名付き証明書タイムスタンプ (SCT, Signed Certificate Timestamp)を発行する。
CTの目的を達成するため、CTログには以下が求められる。
ログとして、完全には有効でなかったり有効期限が切れていたりする証明書を受け入れることもあり得る。
CT monitors（モニター、監視）.
モニターは、記録されていくログを監視する役割のシステムである。
また、関心のある証明書の登録の監視を行う場合もある。
たとえば、自らの所有するドメインが無断で発行されていないか監視するという利用方法があり、複数社がそのためのサービスを提供している。
CT auditors（監査）.
モニターがログ内の個々の証明書に関心を有する存在である一方、ログ全体の整合性を検証する役割が監査者 (auditor)である。
ユーザーエージェントの対応.
Google ChromeおよびSafariでは、HTTPS通信の際にサーバー証明書に対してCTに対応していることを要求する。非対応であれば証明書を信頼せず通信を中断する。対応していることの判定として、ウェブサーバーからSCTが得られることを要求している。
Google Chromeの場合、この処理は以下の条件で適用される。
Safariでは、2018年10月15日以降に発行のサーバー証明書に対してCTへの対応を要求している。
歴史.
2013年3月、Googleは最初のCTログサービスを開始した。
同年9月、DigiCertがCTを実装する最初の認証局となった。
2015年、Google Chromeは新規のEV証明書に対しCTを必須にした。
さらに、ドメイン所有者が認知していない証明書発行が計187件確認されたため、Google Chromeは2016年6月1日以降にSymantecが新規発行する証明書すべてにCTを要求し始めた。
その後、CTを必須とする要件は2018年4月より後（すなわち5月以降）のすべてのTLS証明書に拡大された。
2018年3月23日、CloudflareはNimbusという名称で自身のCTログの開始をアナウンスした。
2018年3月、インターネットドラフト“Certificate Transparency Version 2.0”が公開された。
2019年5月、認証局の1つであるLet's EncryptがOakという名称でCTログを開始した。
2020年2月からは承認されたログリストに追加され、すべての公開認証局で使用可能となっている。