# CT 日志是什么？定义、例子与常见误区

> CT 日志是由独立运营方维护、可公开审计且只可追加的服务器，用 Merkle 树记录证书，并签发承诺收录的时间戳。

Source: https://ssl.sh/zh/glossary/ct-log/
Last updated: 2026-11-10

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

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

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

```bash
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 本该签发这张证书。

## 相关术语

- [证书透明度](https://ssl.sh/zh/glossary/certificate-transparency/): 证书透明度（CT）是一套公开、只可追加的日志系统，记录所有公开信任的 TLS 证书，让任何人都能审计 CA 签发了什么。
- [SCT](https://ssl.sh/zh/glossary/sct/): SCT 是 CT 日志签发的承诺凭证，表示它会把某张证书收录进公开日志，浏览器以此确认证书已提交记录。
- [预证书](https://ssl.sh/zh/glossary/precertificate/): 预证书是 CA 在正式签发前提交到 CT 日志的证书副本，带有“毒化”扩展而无法使用，用来换取 SCT。
- [证书颁发机构](https://ssl.sh/zh/glossary/certificate-authority/): 证书颁发机构（CA）是负责审核申请者、签发数字证书，并把公钥与域名或身份绑定在一起的机构。
- [哈希函数](https://ssl.sh/zh/glossary/hash-function/): 哈希函数（密码学哈希函数）把任意长度的输入映射为固定长度的摘要，且在计算上无法逆推输入，也无法找到摘要相同的两个输入。
- [错误签发](https://ssl.sh/zh/glossary/misissuance/): 错误签发是指 CA 违反 Baseline Requirements 或根证书计划政策签发证书，从验证缺陷到字段格式错误都算在内。