摘要

  • Let's Encrypt 在 2020 年 2 月 29 日披露，证书机构软件 Boulder 在处理包含多个名称的证书请求时，对 DNS CAA 记录的复核存在缺陷 [1]。
  • RFC 8659 将 CAA 定义为 DNS 资源记录，域名持有人可通过它说明哪些证书机构被授权为该域名签发证书 [2]。
  • 责任问题不是 Let's Encrypt 是否总体支持 CAA，而是每一个复用旧验证的相关名称，在签发前是否获得了足够新的授权检查 [1]。
  • Let's Encrypt 官方页面说明该服务由 Internet Security Research Group 提供。BTW 生产目录中当前使用既有的 internet-society 实体，但文章事实主体仍是 Let's Encrypt/ISRG 服务本身 [3]。

事件经过

Let's Encrypt 的事故说明称，2020 年 2 月 29 日在 Boulder 中发现了缺陷。Boulder 通常在验证订阅者对域名的控制权时检查 CAA 记录。由于部分域名控制验证可在初始检查后一段时间内继续使用，证书机构在签发前可能需要再次检查 CAA。Let's Encrypt 表示，当验证时间已经超过相应窗口时，规则要求在签发前八小时内完成 CAA 检查 [1]。

缺陷的形态很具体：当一个证书请求包含多个需要 CAA 复核的域名时，Boulder 会选择其中一个域名并重复检查它，而不是逐一检查所有相关名称。结果是，某个请求可能通过签发流程，即使其中一个或多个名称没有获得预期的最新 DNS 授权检查。Let's Encrypt 称，03:08 UTC 确认缺陷，03:10 UTC 停止签发，05:22 UTC 部署修复，随后恢复签发 [1]。

这条时间线重要，是因为证书机构的责任不能只靠“代码已经修好”来证明。系统还必须识别可能受影响的证书、通知订阅者、允许替换，并完成撤销。公开记录因此包含三个阶段：缺陷识别、签发路径修复、证书生命周期清理 [1]。

为什么 CAA 是 DNS 控制

RFC 8659 将 CAA 描述为域名持有人指定授权证书机构的 DNS 记录，并称它是降低意外错误签发风险的附加控制 [2]。这意味着 CAA 是域名 DNS 状态与证书机构签发决定之间的控制边界。

对网络基础设施责任来说，关键不在证书品牌，而在运行授权链：域名所有者发布 CAA，DNS 基础设施返回证书机构看到的记录状态，证书机构软件解释该状态，订阅者自动化系统期望续期稳定工作，依赖方相信公开证书是在当前授权下签发的。如果这些步骤都被压缩成“验证通过”，证据边界就会变得过软。

目录边界

本文直接事实主体是 Let's Encrypt 及官方来源描述的 ISRG 服务。生产目录使用 entity:internet-society，因为该实体已发布，并且 BTW 生产库中已有 Let's Encrypt 相关证书信任文章采用同一绑定。这并不表示 Internet Society 做出了 Boulder 的工程决策。若最终 owner gate 要求直接 ISRG 实体，候选应精确停机，而不是错误归因。

应保留的证据

可靠的收尾应回答：哪些名称需要新的 CAA 检查，证书机构依赖了哪些 DNS 答案，哪条软件路径作出签发决定，哪些证书可能受影响，订阅者如何收到通知并替换证书，以及之后如何证明同类问题不会复发。没有这些证据，修复就只是公开信任链中的私有声明。

来源

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/