证书透明度

Background

CT日志建立在Merkle树数据结构的基础上。节点用其子节点的加密哈希进行标记。叶节点包含实际数据块的哈希。因此，根节点的标签取决于树中所有其他节点。

在证书透明度的上下文中，叶节点哈希的数据是当前运行的各种不同 CA 所签发的证书。证书的包含可以通过审计证明进行验证，该证明可以高效地生成和验证，时间复杂度为对数 O(log n)。

证书透明度最初出现于 2013 年，背景是 CA 遭遇了多次安全事件（2011 年的 DigiNotar 泄露事件）、有争议的决定（2012 年的 Trustwave 子根事件）以及技术签发问题（马来西亚 DigiCert Sdn Bhd 签发弱的 512 位证书）。

实现

当证书提交到 CT 日志时，会生成一个已签名的证书时间戳 (SCT) 并返回。这作为证书已被提交并将被添加到日志中的证明。

规范指出，符合要求的服务器在与 TLS 客户端连接时必须提供多个 SCT。这可以通过多种不同机制实现：

• X.509v3 证书扩展，将已签名的证书时间戳直接嵌入到叶证书中
• 在握手过程中发送的类型为 signed_certificate_timestamp 的 TLS 扩展
• OCSP 钉扎（即 status_request TLS 扩展），并提供一个带有零个或多个 SCT 的 SignedCertificateTimestampList

对于 X.509 证书扩展，包含的 SCT 由签发 CA 决定。自 2021 年 6 月起，大多数积极使用且有效的公开受信任证书都在此扩展中嵌入了透明度数据。此方法不应需要修改 Web 服务器。

对于后几种方法，需要更新服务器以发送所需数据。优点是服务器运营商可以自定义通过 TLS 扩展/钉扎的 OCSP 响应发送的 SCT 的 CT 日志源。

浏览器要求

Google Chrome 107 及更高版本要求对所有 notBefore 日期在 2018 年 4 月 30 日之后的证书包含 CT 日志。用户将无法访问使用不符合要求的 TLS 证书的网站。Chrome 此前已要求对扩展验证 (EV) 和 Symantec 签发的证书包含 CT。

Apple 要求 Safari 和其他服务器信任服务器证书需要不同数量的 SCT。

Firefox 桌面版 135 版本起要求包含由 Mozilla 根证书颁发机构计划中的证书颁发机构签发的证书的 CT 日志。Firefox for Android 目前不要求包含 CT 日志。

规范

浏览器实现基于已废弃的规范 RFC 6962: Certificate Transparency（2025 年 1 月）。当前规范是 RFC 9162: Certificate Transparency Version 2.0。

另见

• Apple 的证书透明度日志计划
• Chrome 的证书透明度日志策略