Certificate Transparency Monitoring is now generally available

证书透明度监控现已全面上线 | Cloudflare 博客

post

证书透明度

SSL

TLS

2026年8月13日

证书透明度监控现已全面上线

Jenny Yang 和 Pravallika Nakarikanti

8分钟阅读时间

复制链接

自2019年我们推出证书透明度监控公开测试版以来，我们一直在为订阅者监控其域名的公共证书透明度（CT）日志中出现的新TLS证书，并通过电子邮件通知。如今，该功能已覆盖超过65万个客户域名。这为用户提供了早期预警：有人在您的域名区域中为某个主机名颁发了证书，让您有机会及时发现误发证书。

这是一个有用的信号，但存在噪音问题，我们自己也深有体会。Cloudflare会代表您颁发大量证书：通用SSL证书续订、高级证书管理器颁发的证书以及备份证书。所有这些证书都会被记录到公共CT日志中，因为未记录的证书将不被Google Chrome和Apple Safari等主流浏览器信任。因此，这种透明度虽然让您能够监控误发证书，但也导致我们为您颁发的每个证书都会触发通知。

证书的颁发并非一次性事件。证书有效期较短且会自动续订：一个通用SSL证书可能每60天续订一次，每年最多续订六次。这一频率将提高，CA/Browser论坛已投票决定将证书最大有效期缩短至2029年的47天，这将使这些日志中的常规续订次数大幅增加。每次续订都会生成警报。但考虑到Cloudflare颁发证书的规模，真正可疑的证书可能看起来和常规续订无异，重要警报很容易被忽略。

我们从客户那里也收到了类似反馈。在我们的社区论坛上，有用户描述自己因为“厌倦了频繁收到大量完全正常的证书续订通知”而关闭了该功能，并补充道：“到最后我甚至根本不再阅读这些通知。”这些噪音正是来自Cloudflare自身的证书。

今天，我们改变了这一状况。证书透明度监控现已在发送警报前过滤掉Cloudflare为您颁发的证书。到达您邮箱的警报都是需要您关注的：那些您未预期且非Cloudflare颁发的证书。通过这一改进，证书透明度监控现已全面上线。

过滤Cloudflare管理的证书

我们的目标是识别并消除常规、由Cloudflare管理的证书颁发和续订带来的噪音警报，同时确保能够捕获所有由外部系统管理的证书。

为什么之前无法识别并过滤这些证书？

存在两个独立系统分别服务于不同产品：证书管理系统处理内部证书颁发数据，而CT警报服务则解析公共CT日志中的数据。

此前：独立的颁发和警报流程

这两个流程处理同一张证书，但从未在相同时间点处理，也从未使用相同信息。当警报流程决定是否向您发送邮件时，它仅能依赖从日志中提取的信息。它无法从颁发流程获得任何信号，例如“订单服务刚刚创建了这张证书”。正是这一缺失环节导致了问题。

证书的生命周期是什么？

如上所述，证书的颁发分为两个阶段：

• 证书颁发机构（CA）创建预证书，写入日志并接收SCT（带时间戳的证书签名）。

• CA将这些SCT嵌入最终证书并记录日志。

因此，告警服务会为一个证书订单看到两个日志条目：1）预证书和2）最终证书。为了避免对每对证书重复告警，内部存储了一个用于去重的标识符stripped_fingerprint。该指纹是DER（可区分编码规则）编码的TBSCertificate（待签名证书）的哈希值。对于属于同一证书订单的预证书/最终证书对，该值保持一致且唯一。因此，这个标识符已经存在，并且完全位于告警流程中。

为什么直观的修复方法会失败？

直观的捷径是将stripped_fingerprint复制到订单服务中，以便告警服务可以查找。但这不起作用，因为订单服务不会接收到预证书，因此当告警服务接收到它时，无法生成该值。

问题：stripped_fingerprint到达时间太晚。

因此，即使使用它作为标识符，也只能在订单服务接收到最终证书后记录。在预证书和最终证书日志条目之间的窗口期，如果告警服务在订单服务的数据库中查找stripped_fingerprint(precert)，将找不到任何匹配该标识符的信息来确认它是否由我们颁发——这又会导致额外的告警。

尽管证书订单服务是回答“这是我们的吗？”的正确系统，但用于唯一标识这些信息的匹配键在竞速中并未胜出。因此，问题被重新表述。问题不再是如何存储指纹，而是从订单创建到最终记录的证书，什么标识符可以被持久化。

正确的密钥是什么？

正确的密钥需要满足以下条件：

• 早期：在任何内容到达日志之前记录，即在密钥生成时就存在。

• 一致性：从预证书到最终证书的所有阶段保持一致。

• 可重复性：CT告警服务可以仅从日志条目中独立重新计算它。

• 唯一性：每个证书订单唯一。

公钥就是这样一个符合所有条件的标识符。它包含在一个名为SubjectPublicKeyInfo（SPKI）的结构中。

解决方案：SPKI保持一致且可重复

一致性：如上图所示，SubjectPublicKeyInfo（SPKI）从第一步开始就存在，并且在CSR（证书签名请求）、预证书和最终证书中保持不变。

唯一性和安全性：Cloudflare为每次颁发生成一组新的密钥对，因此公钥在实际使用中是唯一的。由于只有Cloudflare拥有私钥，带有匹配SPKI的证书只能来自Cloudflare的颁发。碰撞的可能性极低，且没有外部人员可以在没有私钥的情况下创建有效的签名请求。

因此，我们记录的标识符是spki_sha256——DER编码的SPKI的SHA-256哈希值，这是一个短且固定长度的值，索引成本低廉。订单服务可以直接从CSR中计算它，并在密钥生成阶段（颁发开始前）写入。

两种流程如何就值达成一致？

在证书排序阶段尽早记录密钥解决了这个问题。有了这一机制，告警流程会增加一个额外步骤。当告警系统发现日志条目时，会重新从证书的公钥中计算spki_sha256值，并在数据库中查询排序服务是否已记录该值：

• 匹配 → 排序服务已记录该密钥，说明证书属于我们。抑制告警。

• 不匹配 → 未找到密钥 → 按照之前的方式触发告警。

由于预证书和最终证书中的密钥完全一致，现在不再需要关心哪个先到达。

已知Cloudflare证书过滤后：

以下三项改进将减少噪音：

• 我们管理的证书将不再触发告警。Universal SSL、Advanced Certificate Manager、Total TLS和Backup Certificates都会匹配已记录的密钥并静默通过。

• 未完成的预证书将不再触发告警。有时预证书会被记录但签发流程未完成。这些告警以前看起来像是无法解释的证书；现在它们会匹配记录并保持静默。事件仍会在我们这边记录，但我们不会再就已知属于我们的内容发送邮件。

• 你上传的自定义证书仍会触发告警。我们未生成这些密钥，因此签发侧没有记录，也没有需要抑制的内容。这正是CT监控和告警存在的意义，且这部分功能保持不变。

此处大部分工作并非编写修复代码，而是充分理解两个流程，认识到连接它们的密钥是一个我们一直携带的字段。一旦选择了一个早期且共享的标识符，其余工作就只是簿记。

CT告警应仅在无法解释的签发情况下触发。通过此次改进，现在确实如此。

告警现在更易于审查

更新后的邮件在主题行中标识受影响的主机名，在邮件正文中包含证书详情，并链接到Cloudflare仪表板中的证书，以便你审查并根据需要采取行动。

告警邮件截图

后续计划

我们计划将证书透明度监控功能引入Cloudflare通知系统。这将允许团队将CT告警路由到webhook、PagerDuty或额外的电子邮件地址，就像管理其他Cloudflare告警一样，而不再依赖当前仅限邮件的通道。

立即体验

已经在使用证书透明度监控？你无需任何操作。过滤功能已默认启用。从今天起，你将仅收到Cloudflare自动化系统之外签发证书的通知。

尚未使用？在Cloudflare仪表板中，前往SSL/TLS → 边缘证书 → 证书透明度监控并开启该功能。该功能在所有计划中均可免费使用，各计划层级设置统一，便于你在一个统一视图中管理告警接收者。

证书透明度监控设置截图

如果你对证书透明度监控的未来发展有想法，请通过你的客户经理或Cloudflare社区告诉我们。这些反馈将影响我们下一步构建的自定义控制功能。

目录列

讨论列

相关标签和社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

电子邮件订阅