证书透明度监控现已全面推出
自从2019年我们推出了<a href="https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/">证书透明度监控公开测试版</a>以来，我们就一直在通过邮件通知订阅者，任何在公共<a href="https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/">证书透明度</a>(CT)日志中为其域名出现的新TLS证书。今天，已经有超过65万个客户域名启用了该功能。这意味着有人在您的域名下颁发了证书，您可以提前发现误颁发的证书。
这是一种有用的信号，但我们也意识到有噪声问题。Cloudflare为您颁发大量证书：包括通用SSL续期、来自高级证书管理器的证书以及备份证书。所有这些证书都会被设计性地记录到公共CT日志中，因为未记录的证书不会被像Google Chrome和Apple的Safari这样的主流浏览器信任。因此，监控误颁发所需的透明度也曝光了我们为您颁发的每一个证书。
而且，证书的颁发并不是一次性事件。证书使用期限短且会自动续期：单个通用SSL证书可以<a href="https://developers.cloudflare.com/ssl/reference/certificate-validity-periods/">每60天续期一次</a>，最多每年可续期六次。这个频率即将增加，<a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods">CA/浏览器论坛</a>已投票决定到2029年将最大证书生命周期缩短至47天，从而增加流经这些日志的例行续订数量。每一次续订都会生成一个警报。但在Cloudflare颁发证书的大规模下，真正可疑的证书可能看起来与例行续期一模一样，因此重要的警报很容易被忽略。
我们也从客户那里听到了同样的反馈。在我们的社区论坛上，有人描述说由于“厌倦了不断收到大量完全正常的证书续期邮件”，他们已在所有站点上禁用此功能，并补充说“到最后我甚至都没有实际阅读它们”。这些噪声正是来自Cloudflare自主颁发的证书。
今天，我们对此进行了改进。证书透明度监控现在会在发送警报之前过滤掉Cloudflare代您颁发的证书。到达您邮箱的警报将仅为那些您未预期且Cloudflare未颁发的证书。
## 过滤掉Cloudflare管理的证书
我们的目标是识别并消除针对例行的Cloudflare管理的证书颁发和续期的无声警报，同时确保我们能够捕获所有由系统外部管理的证书。
### 为什么我们之前不能仅仅识别并过滤这些？
存在两个独立的系统，分别服务于不同的产品：证书管理，处理内部证书颁发数据，以及CT警报服务，它解析来自公共CT日志的数据。
这两个流程处理同一证书，但从不同时刻进行，也从不使用相同的信息。当警报流程决定是否发送邮件给您时，它所能获得的仅仅是从日志中提取的数据。它没有来自颁发流程的信号来说明“订购服务刚刚创建了这个”。这个缺失的链接正是问题所在。
### 证书的生命周期是什么样的？
如上所示，<a href="https://datatracker.ietf.org/doc/html/rfc6962?cf_target_id=FB76C3BCC6BDA462922440973DD1A472">证书颁发</a>分为两个阶段：
1. 证书颁发机构（CA）创建预证书，记录到日志中并接收<a href="https://blog.cloudflare.com/another-look-at-pq-signatures/#the-signatures-in-tls">SCTs</a>(签名证书时间戳)。
2. CA将这些SCT嵌入最终证书中并记录。
因此，警报服务会看到针对单个证书订单的两个日志条目：1) 预证书和2) 最终证书。为避免针对每对条目重复警报，内部标识符<code>stripped_fingerprint</code>被存储用于去重目的。该指纹是DER（区分编码规则）编码的TBSCertificate（待签名证书）的哈希值。此值在属于同一证书订单的预证书/最终证书对中保持一致且唯一。因此，这是一个已经存在的标识符，完全位于警报流程内部。
### 为什么显而易见的解决方案无效？
直观的快速解决方案是将<code>stripped_fingerprint</code>复制到订购服务中，方便警报服务查找。但这并无效，因为订购服务没有接收到预证书，因此在警报服务接收到时无法生成该值。
因此，即使将其用作标识符，也只能在最终证书由订购服务接收之后记录。在预证书和最终证书日志条目之间的这个窗口中，如果警报服务在订购服务的数据库中查找<code>stripped_fingerprint(precert)</code>，那么它将找不到任何与该标识符匹配的信息来确认这是我们颁发的——这又会导致额外警报。
虽然证书订购服务是回答"这是否属于我们的"的正确系统，但识别该信息的匹配关键在比赛中失败了。所以问题重新转化。问题不再是存储指纹的地方，而是在订单创建到最终记录的证书之间能够持续存在的唯一标识符是什么。
### 什么是正确的关键？
正确的关键必须满足以下条件：
1. **提前**：在任何内容到达日志之前记录，即在密钥生成时存在。
2. **一致**：从预证书到最终证书的所有阶段保持一致。
3. **可重现**：CT警报服务可以独立从日志条目重新计算。
4. **唯一**：每个证书订单状态唯一。
**公钥**是一个满足所有这些条件的标识符。它在名为<code>SubjectPublicKeyInfo</code>(SPKI)的结构中传播。
**一致性**：如上图所示，<code>SubjectPublicKeyInfo</code>(SPKI)从第一步开始就存在，并在CSR（证书签名请求）、预证书和最终证书中保持不变。
**唯一性和安全性**：Cloudflare为每次颁发生成一对新的密钥，因此公钥实际上是唯一的。由于只有Cloudflare拥有私钥，因此具有匹配SPKI的证书必须来自Cloudflare的颁发。发生碰撞的可能性极小，并且任何外部人员无法在没有私钥的情况下创建有效的签名请求。
因此我们记录的标识符是<code>spki_sha256</code>——SPKI的SHA-256哈希，这是一个短固定长度的值，便于索引。订购服务直接从CSR计算该值，并在密钥生成时写入，在整个颁发开始之前。
### 两个流程如何一致于该值？
在证书订购中提前记录该密钥解决了这个问题。确保这样后，警报流程执行额外步骤。当警报查看到日志条目时，它根据证书的公钥重新计算<code>spki_sha256</code>，并查找订购服务是否在其数据库中记录了该值——
- **匹配** → 订购服务记录了该密钥，因此证书是我们的。抑制警报。
- **无** **匹配** → 找不到密钥——发送警报，和之前一样。
因为该密钥在预证书和最终证书中是相同的，所以不再重要哪个先到达。
随之而来的三件事，都是为了减少噪声：
- **我们管理的证书不再警报**。通用SSL、高级证书管理器、总TLS和备份证书都与已记录的密钥匹配并保持安静。
- **被放弃的预证书不再警报**。有时预证书被记录但颁发未完成。那些警报通常看起来像不明证书；现在它们与记录匹配并保持安静。事件仍在我们一侧记录；我们只是不再给您发送已经知道的证书的邮件。
- **您上传的自定义证书仍然会警报**。我们没有生成那些密钥，因此在颁发方没有记录的情况下无法抑制。正是CT监控和警报存在的目的，并且未受影响。
这里大部分工作不是编写修复措施，而是充分了解这两个流程，以了解到连接它们的关键是我们一直携带的字段。一旦我们选择了早期且共享的标识符，其余就是记录工作。
CT警报应该仅在我们无法核算的颁发时触发。通过这一更改，它实现了。
## 警报现在更易于审查
更新后的电子邮件在主题行中识别受影响的主机名，消息中包括证书详细信息，并链接到Cloudflare仪表板中的证书，方便您审查并根据需要采取行动。
## 下一步是什么
我们计划将证书透明度监控引入<a href="https://developers.cloudflare.com/notifications/">Cloudflare通知</a>。这将让团队将CT警报路由到网络钩子、PagerDuty或其他电子邮件目的地，正如他们管理其他Cloudflare警报，而不再依赖今天仅限电子邮件的渠道。
## 试试吧
已经在使用证书透明度监控？您无需采取任何措施。过滤功能已自动启用。从今天开始，您只会收到有关Cloudflare自动系统外发出的证书的通知。
尚未使用？请在<a href="https://dash.cloudflare.com/">Cloudflare仪表板</a>中，前往SSL/TLS → 边缘证书 → 证书透明度监控，启用此功能。所有计划均无额外费用，跨计划层的统一设置，方便您在一个一致的视图中管理警报接收者。
如果您对证书透明度监控的演变有想法，请通过您的账户团队或<a href="https://community.cloudflare.com/top?period=daily">Cloudflare社区</a>告知我们。这些反馈将塑造我们接下来构建的自定义控制。
---
原文链接：[点击查看](https://blog.cloudflare.com/certificate-transparency-monitoring-ga/)
这是一种有用的信号，但我们也意识到有噪声问题。Cloudflare为您颁发大量证书：包括通用SSL续期、来自高级证书管理器的证书以及备份证书。所有这些证书都会被设计性地记录到公共CT日志中，因为未记录的证书不会被像Google Chrome和Apple的Safari这样的主流浏览器信任。因此，监控误颁发所需的透明度也曝光了我们为您颁发的每一个证书。
而且，证书的颁发并不是一次性事件。证书使用期限短且会自动续期：单个通用SSL证书可以<a href="https://developers.cloudflare.com/ssl/reference/certificate-validity-periods/">每60天续期一次</a>，最多每年可续期六次。这个频率即将增加，<a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods">CA/浏览器论坛</a>已投票决定到2029年将最大证书生命周期缩短至47天，从而增加流经这些日志的例行续订数量。每一次续订都会生成一个警报。但在Cloudflare颁发证书的大规模下，真正可疑的证书可能看起来与例行续期一模一样，因此重要的警报很容易被忽略。
我们也从客户那里听到了同样的反馈。在我们的社区论坛上，有人描述说由于“厌倦了不断收到大量完全正常的证书续期邮件”，他们已在所有站点上禁用此功能，并补充说“到最后我甚至都没有实际阅读它们”。这些噪声正是来自Cloudflare自主颁发的证书。
今天，我们对此进行了改进。证书透明度监控现在会在发送警报之前过滤掉Cloudflare代您颁发的证书。到达您邮箱的警报将仅为那些您未预期且Cloudflare未颁发的证书。
## 过滤掉Cloudflare管理的证书
我们的目标是识别并消除针对例行的Cloudflare管理的证书颁发和续期的无声警报，同时确保我们能够捕获所有由系统外部管理的证书。
### 为什么我们之前不能仅仅识别并过滤这些？
存在两个独立的系统，分别服务于不同的产品：证书管理，处理内部证书颁发数据，以及CT警报服务，它解析来自公共CT日志的数据。
这两个流程处理同一证书，但从不同时刻进行，也从不使用相同的信息。当警报流程决定是否发送邮件给您时，它所能获得的仅仅是从日志中提取的数据。它没有来自颁发流程的信号来说明“订购服务刚刚创建了这个”。这个缺失的链接正是问题所在。
### 证书的生命周期是什么样的？
如上所示，<a href="https://datatracker.ietf.org/doc/html/rfc6962?cf_target_id=FB76C3BCC6BDA462922440973DD1A472">证书颁发</a>分为两个阶段：
1. 证书颁发机构（CA）创建预证书，记录到日志中并接收<a href="https://blog.cloudflare.com/another-look-at-pq-signatures/#the-signatures-in-tls">SCTs</a>(签名证书时间戳)。
2. CA将这些SCT嵌入最终证书中并记录。
因此，警报服务会看到针对单个证书订单的两个日志条目：1) 预证书和2) 最终证书。为避免针对每对条目重复警报，内部标识符<code>stripped_fingerprint</code>被存储用于去重目的。该指纹是DER（区分编码规则）编码的TBSCertificate（待签名证书）的哈希值。此值在属于同一证书订单的预证书/最终证书对中保持一致且唯一。因此，这是一个已经存在的标识符，完全位于警报流程内部。
### 为什么显而易见的解决方案无效？
直观的快速解决方案是将<code>stripped_fingerprint</code>复制到订购服务中，方便警报服务查找。但这并无效，因为订购服务没有接收到预证书，因此在警报服务接收到时无法生成该值。
因此，即使将其用作标识符，也只能在最终证书由订购服务接收之后记录。在预证书和最终证书日志条目之间的这个窗口中，如果警报服务在订购服务的数据库中查找<code>stripped_fingerprint(precert)</code>，那么它将找不到任何与该标识符匹配的信息来确认这是我们颁发的——这又会导致额外警报。
虽然证书订购服务是回答"这是否属于我们的"的正确系统，但识别该信息的匹配关键在比赛中失败了。所以问题重新转化。问题不再是存储指纹的地方，而是在订单创建到最终记录的证书之间能够持续存在的唯一标识符是什么。
### 什么是正确的关键？
正确的关键必须满足以下条件：
1. **提前**：在任何内容到达日志之前记录，即在密钥生成时存在。
2. **一致**：从预证书到最终证书的所有阶段保持一致。
3. **可重现**：CT警报服务可以独立从日志条目重新计算。
4. **唯一**：每个证书订单状态唯一。
**公钥**是一个满足所有这些条件的标识符。它在名为<code>SubjectPublicKeyInfo</code>(SPKI)的结构中传播。
**一致性**：如上图所示，<code>SubjectPublicKeyInfo</code>(SPKI)从第一步开始就存在，并在CSR（证书签名请求）、预证书和最终证书中保持不变。
**唯一性和安全性**：Cloudflare为每次颁发生成一对新的密钥，因此公钥实际上是唯一的。由于只有Cloudflare拥有私钥，因此具有匹配SPKI的证书必须来自Cloudflare的颁发。发生碰撞的可能性极小，并且任何外部人员无法在没有私钥的情况下创建有效的签名请求。
因此我们记录的标识符是<code>spki_sha256</code>——SPKI的SHA-256哈希，这是一个短固定长度的值，便于索引。订购服务直接从CSR计算该值，并在密钥生成时写入，在整个颁发开始之前。
### 两个流程如何一致于该值？
在证书订购中提前记录该密钥解决了这个问题。确保这样后，警报流程执行额外步骤。当警报查看到日志条目时，它根据证书的公钥重新计算<code>spki_sha256</code>，并查找订购服务是否在其数据库中记录了该值——
- **匹配** → 订购服务记录了该密钥，因此证书是我们的。抑制警报。
- **无** **匹配** → 找不到密钥——发送警报，和之前一样。
因为该密钥在预证书和最终证书中是相同的，所以不再重要哪个先到达。
随之而来的三件事，都是为了减少噪声：
- **我们管理的证书不再警报**。通用SSL、高级证书管理器、总TLS和备份证书都与已记录的密钥匹配并保持安静。
- **被放弃的预证书不再警报**。有时预证书被记录但颁发未完成。那些警报通常看起来像不明证书；现在它们与记录匹配并保持安静。事件仍在我们一侧记录；我们只是不再给您发送已经知道的证书的邮件。
- **您上传的自定义证书仍然会警报**。我们没有生成那些密钥，因此在颁发方没有记录的情况下无法抑制。正是CT监控和警报存在的目的，并且未受影响。
这里大部分工作不是编写修复措施，而是充分了解这两个流程，以了解到连接它们的关键是我们一直携带的字段。一旦我们选择了早期且共享的标识符，其余就是记录工作。
CT警报应该仅在我们无法核算的颁发时触发。通过这一更改，它实现了。
## 警报现在更易于审查
更新后的电子邮件在主题行中识别受影响的主机名，消息中包括证书详细信息，并链接到Cloudflare仪表板中的证书，方便您审查并根据需要采取行动。
## 下一步是什么
我们计划将证书透明度监控引入<a href="https://developers.cloudflare.com/notifications/">Cloudflare通知</a>。这将让团队将CT警报路由到网络钩子、PagerDuty或其他电子邮件目的地，正如他们管理其他Cloudflare警报，而不再依赖今天仅限电子邮件的渠道。
## 试试吧
已经在使用证书透明度监控？您无需采取任何措施。过滤功能已自动启用。从今天开始，您只会收到有关Cloudflare自动系统外发出的证书的通知。
尚未使用？请在<a href="https://dash.cloudflare.com/">Cloudflare仪表板</a>中，前往SSL/TLS → 边缘证书 → 证书透明度监控，启用此功能。所有计划均无额外费用，跨计划层的统一设置，方便您在一个一致的视图中管理警报接收者。
如果您对证书透明度监控的演变有想法，请通过您的账户团队或<a href="https://community.cloudflare.com/top?period=daily">Cloudflare社区</a>告知我们。这些反馈将塑造我们接下来构建的自定义控制。
---
原文链接：[点击查看](https://blog.cloudflare.com/certificate-transparency-monitoring-ga/)
评论
暂无评论。