証明書の透明性

CT ログは Merkle ツリーのデータ構造をベースに構築されています。ノードには子ノードの暗号化ハッシュがラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。

Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる監査証明を介して検証することができます。

Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。

証明書が CT ログに送信されると、署名付き証明書のタイムスタンプ (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。

仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供しなければならないとされています。これは、いくつかの異なるメカニズムを介して実現することができます。

• 署名付き証明書のタイムスタンプを直接リーフ証明書に埋め込む X.509 v3 証明書拡張機能
• ハンドシェイク中に送信される signed_certificate_timestamp 型の TLS 拡張
• OCSP のステープリング (つまり、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 であっても)。