CT 日志 （Certificate Transparency Log）

CT 日志是由独立运营方运行的服务器：它接收 CA 提交的证书和预证书，追加到 Merkle 树中，并返回 SCT（签名证书时间戳）。日志会定期发布签名树头（STH）。任何人都可以请求“包含证明”，确认某张证书确实在树里；也可以请求“一致性证明”，确认这棵树只增长、从未被改写。每个日志都承诺在最大合并延迟（MMD）内把新条目并入树中。

为什么重要

浏览器并不接受任意日志的 SCT：日志必须被纳入 Chrome、Apple 等浏览器的 CT 策略，并接受持续监控。如果日志对不同的人展示不同的内容，或者没能按时合并条目，就可能被取消资格，此后它签发的 SCT 不再算数。日志通常按时间分片，不同到期时间段的证书进入不同的日志，旧分片可以冻结并退役。Google、Cloudflare、DigiCert、Sectigo、Let's Encrypt 等都运营过日志，这让证书透明度不依赖任何单一公司。

例子

遵循 RFC 6962 的日志提供简单的 HTTP 接口，例如获取当前树头：

curl -s https://ct.example.com/ct/v1/get-sth

返回的 JSON 包含 tree_size、timestamp、sha256_root_hash 和 tree_head_signature。监控方定期轮询这个接口，再用 get-entries 下载新条目。一些较新的日志（例如运行 Let's Encrypt 的 Sunlight 软件的日志）则改为以静态分块（tile）的形式提供整棵树。

常见误区

• 存在一个中心化的 CT 日志。 实际上有很多独立日志，浏览器要求 SCT 来自多个不同的日志运营方。
• CT 日志会校验证书是否合规。 日志只检查提交的证书能否链到它接受的根证书，判断签发是否正确是监控方的工作。
• 证书进了日志就说明它是合法的。 记入日志是浏览器接受证书的前提，但并不说明 CA 本该签发这张证书。