证书透明度

证书被错误签发时，单个客户端未必知道域名持有者并未申请它。透明度日志把已观察到或提交的证书及预证书资料纳入可查询记录，让关注某域名的一方监测意外签发，而不是只依赖访问过该站点的人偶然发现。

日志不是重新判断网站业务是否可信的CA，也不自动阻止所有误签。发现异常后还需要现有撤销、信任锚管理或其他处置；RFC 9162描述的是实验性质的CT 2.0协议，本文用它说明机制，不把所有浏览器部署都等同于这一版本。

参考：[1]

Merkle树把有序日志条目通过哈希归约成树根。包含证明给出重建相应根所需的部分节点，使验证者确认某一条目位于指定大小和树根的日志快照中，不必为单个检查下载全部历史。

一致性证明则比较较小与较大两个树状态，证明早先的条目仍作为后者的相同前缀保留。它关注日志增长没有改写过去，不能只用某条目的包含证明代替；证明也须对应实际信任并核验的日志签名及树状态。

参考：[1]

SCT是日志对证书提交作出的签名承诺，日志须在所声明的最大合并延迟内把相应条目纳入。收到SCT不等于已经得到包含证明；客户端或监测者可在时限后索取证明，检查承诺是否兑现。

监测者还检查新增条目及树状态一致性。作恶日志可能向不同观察者展示彼此冲突的视图，单方只看自己的一份证明并不能排除这种分裂；跨观察者比较有助于发现它。公开日志也会暴露原本难以发现的域名信息，透明性因此同时带来监测价值与隐私边界。

参考：[1]