Certificate Transparency は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。
このようにして、認証局 (CA) は、はるかに大きな監視と監督を受けることができます。CA/B フォーラムのベースライン要件に違反するような、潜在的に悪意のある証明書は、より迅速に検出され、失効される可能性があります。また、ブラウザベンダーやルートストアのメンテナは、不信に繋がるかもしれない問題がある CA について、より多くの情報に基づいた決定を下すことができるようになります。
CT ログは Merkle ツリーのデータ構造をベースに構築されています。ノードには子ノードの暗号化ハッシュがラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。
Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる監査証明を介して検証することができます。
Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。
証明書が CT ログに送信されると、署名付き証明書のタイムスタンプ (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。
仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供しなければならないとされています。これは、いくつかの異なるメカニズムを介して実現することができます。
signed_certificate_timestamp 型の TLS 拡張status_request TLS 拡張) と、1つ以上の SCT を持つ SignedCertificateTimestampList の提供X.509 証明書の拡張では、含まれる SCT は発行 CA が決定します。このメカニズムを使用する場合、Web サーバを変更する必要はありません。
後者の方法では、必要なデータを送信するためにサーバを更新する必要があります。利点は、サーバオペレータが TLS 拡張/stapled OCSP レスポンスを介して送信される SCT を提供する CT ログソースをカスタマイズできることです。
Google Chrome では、2018年4月30日以降の notBefore 日付を持つすべての証明書の問題に対して、CT ログのインクルードを要求しています。これにより、ユーザーは非準拠の TLS 証明書を使用したサイトを訪問できなくなります。これまで Chrome では、Extended Validation (EV) や Symantec が発行した証明書に対して CT のインクルードが義務付けられていました。
Apple は、Safari や他のサーバがサーバ証明書を信頼するために、さまざまな数の SCT を必要としています。
Firefox は現在、ユーザーが訪問したサイトの CT ログを確認したり、使用を義務付けたりしていません。
Expect-CT ヘッダを使用して、ブラウザが証明書の透過性の要件を常に実施するように要求することができます (Chrome などでは、証明書の発行日が4月以前の notBefore であっても)。
| 仕様書 | ステータス | コメント |
|---|---|---|
| Certificate Transparency | IETF RFC |