证书透明度
证书透明度是一个开放框架，旨在防止和监控证书误发。它在 RFC 9162 中定义。使用证书透明度，新颁发的证书会被“记录”到公开运行的、通常是独立的 CT 日志 中，这些日志维护着已颁发 TLS 证书的附加专用、密码学保证记录。
通过这种方式，证书颁发机构 (CA) 可以受到更大的公众监督和审查。可能存在恶意证书，例如违反 CA/B 论坛 基准要求 的证书，可以更快地检测和撤销。浏览器供应商和根证书存储维护者也能够做出更明智的决定，以决定他们可能不信任的问题 CA。
背景
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_requestTLS 扩展）并提供包含一个或多个 SCT 的SignedCertificateTimestampList
对于 X.509 证书扩展，包含的 SCT 由颁发证书的 CA 决定。自 2021 年 6 月以来，大多数积极使用且有效的公开信任证书都包含嵌入在该扩展中的透明度数据。此方法不应该要求修改 Web 服务器。
对于后一种方法，需要更新服务器以发送所需数据。优点是服务器运营商可以自定义通过 TLS 扩展/钉扎的 OCSP 响应发送的 SCT 的 CT 日志来源。