证书透明度日志监控第2页：CT技术体系、数据结构与标准演进

01 · 日志与Merkle树

CT日志是一个仅追加（append-only）的数据结构：所有证书条目按到达顺序排列，组织为Merkle哈希树。每个条目（叶子）是证书数据的哈希，相邻叶子两两哈希合并直至树根，树根连同树大小与时间戳由日志密钥签名为STH（Signed Tree Head）。Merkle树的密码学性质赋予CT三项核心能力：

• 防篡改：任何对历史条目的修改都会改变根哈希，与已发布的STH冲突；
• 收录证明（Inclusion Proof）：日志可出具O(log n)大小的审计路径，证明某条目确实在该树中；
• 一致性证明（Consistency Proof）：证明新树是在旧树基础上追加而来、未篡改历史——这是"仅追加"承诺的密码学基础。

02 · 证书时间戳（SCT）机制

SCT（Signed Certificate Timestamp）是日志对"我已承诺在MMD内收录该证书"的签名承诺。RFC 6962 SCT结构为：version（v1）、log_id、timestamp、extensions、signature（签名覆盖日志ID、时间戳、扩展字段与叶子数据哈希）。

2.1 SCT的三种交付方式

浏览器连接站点时验证SCT：检查SCT签名有效性、时间戳合理性、日志是否在自身认可的日志列表中、数量是否满足政策要求。任一不满足即按证书错误处理（对不满足CT要求的证书降级或拒绝）。

03 · 预证书（Precertificate）机制

经典问题：CA若先签发最终证书再提交日志，则最终证书本身要先获得SCT才能签发——存在"先有鸡还是先有蛋"的循环。RFC 6962的解法是预证书（Precertificate）：

1. CA构造一份与最终证书几乎相同的TBSCertificate，但注入一个特殊的毒化扩展（CT Poison，OID 1.3.6.1.4.1.11129.2.4.3），使其永远无法作为有效证书被浏览器接受；
2. CA用CT Precertificate Signing Certificate（专门的预签名证书，由CA证书签名）对毒化TBSCertificate签名，形成precertificate，通过add-pre-chain提交日志；
3. 日志返回SCT，CA随后签发去掉毒化扩展的最终证书；
4. 最终证书同样会被CA或日志抓取方提交日志（形成X509Entry），保证"最终证书必然可检索"。

因此同一次签发在日志中通常留下两条记录（PrecertEntry + X509Entry），precert的SCT时间戳通常比最终证书早数秒至数分钟。监测管道必须对二者去重归并，否则告警量与存储成本近乎翻倍（第3页§06）。CT v2（RFC 9162）对该机制进行了重构（见§05）。

04 · 监控者与审计者

RFC 6962定义了日志之外的两种客户端角色，本课题的监测管道本质上是"监控者"的工程实现：

两类角色共享同一数据面，区别在于对数据的使用目的。工程实践中，同一份管道应同时承担监控职能，并对关键日志抽样执行审计职能（比对多个监控源的STH，可有效发现日志分裂视图——即不同客户端看到不同日志内容）。

05 · CT v2（RFC 9162）与Gossip（RFC 9163）

2021年12月，IETF发布CT v2（RFC 9162），同时废黜（obsolete）RFC 6962；配套发布Gossip协议RFC 9163。CT v2的主要变化包括：

• 统一叶子格式：叶子仅承载TBSCertificate（与传输方式无关），消除了v1中X509Entry/PrecertEntry双类型带来的冗余记录问题；
• 预证书重构：precertificate改为CMS封装对象，不再使用CT Precertificate Signing Certificate与毒化扩展，CA提交流程简化；
• 传输重构：引入TransItem通用结构承载SCT/SCT反馈等对象；TLS侧以transparency_info扩展替代signed_certificate_timestamp扩展；
• 日志标识：日志以OID标识（区别于v1的公钥哈希Log ID）。

现实部署状况：CT v2未获产业界实际部署。公开讨论中（包括Let's Encrypt工程师在内的社区成员多次表态），生态对v2持观望态度，产业演进的实际重心转向Chrome主导、由Sunlight与Static CT API开创的静态日志路线（见§06、第7页）。Gossip（RFC 9163）旨在通过客户端间交换日志情报（SCT、STH签名等）检测日志合谋与分裂视图，同样未大规模落地——浏览器更多依赖自身日志列表与合规监测体系实现等效保障。

06 · Static CT API与日志架构现代化

传统RFC 6962日志是"有状态"服务：维护动态Merkle树、处理并发追加、承诺MMD窗口，运维复杂度高（分片数据库可达数TB级），且MMD违约将导致日志被浏览器列表移除。2023年起，Chrome日志政策开始接受一种新的静态架构——Static CT API（现由C2SP组织标准化，前身即Let's Encrypt与Filippo Valsorda合作发布的Sunlight API），其核心设计：

2025—2026年是静态化的落地高峰：Let's Encrypt基于Sunlight构建的生产日志Sycamore与Willow于2025年11月获得Chrome日志列表准入资格，其全部RFC 6962日志已于2025年11月30日转为只读、2026年2月28日停止服务；Cloudflare、Google（Trillian Tessera）、IPng等亦推出静态实现。监测管道必须在RFC 6962与Static CT双协议下同时采集——这是第3页的核心工程命题。

07 · 浏览器CT政策对比

注：上表为政策要点归纳，细则（含EV证书历史要求、过渡期安排）以各官方政策页为准：Chrome CT Policy（github.com/GoogleChrome/CertificateTransparency）、Apple支持文档103214。

7.1 日志列表治理对监测的意义

• 覆盖基线：监测范围应等于 Chrome日志列表 ∪ Apple日志列表 中的活跃日志——两份列表有交集但互不替代（例如历史上曾出现仅被一方认可的日志）。
• 分片到期：日志按时间分片到期停收新条目，管道须跟踪日志列表变更（新增/到期/移除），避免采集中断产生盲区。
• 合规威慑：日志可用性低于99%、MMD违约、密钥管理违规均会导致日志被移除——这保证了日志数据的整体可信度，也是"审计者"职能的现实依托。

08 · 标准与政策文件清单

本节参考来源（第2页）

本节机制性内容全部对应RFC/规范原文；政策类内容以浏览器官方页面为准。