Boulder项目中CAA多视角验证机制的优化演进

在证书颁发机构(CA)的运作中，CAA(Certification Authority Authorization)记录是域名所有者控制哪些CA可以为其颁发证书的重要DNS机制。作为Let's Encrypt的核心系统，Boulder项目近期对其CAA验证机制进行了重要改进，本文将深入解析这一技术演进过程。

背景与问题

传统的CAA验证存在两个关键挑战：

1. 视角单一性：早期的验证仅从本地DNS解析器视角检查CAA记录，这可能导致因本地DNS缓存或配置问题而产生误判。

2. 时间窗口风险：验证与颁发之间存在时间差（最长7小时），期间DNS记录可能发生变化，而系统仅在颁发时重新检查本地视角的CAA记录。

2020年的一次事故表明，这种实现与CA/B论坛基准要求(BRs)存在偏差——BRs明确规定CAA检查应是颁发时的要求，而非验证时的要求。

技术解决方案演进

项目团队提出了三种改进方案：

1. 基础增强方案：直接在现有VA.IsCAAValid函数中增加远程视角检查。

2. 模块化重构方案：

   • 新增VA.IsCAAValidMPIC方法实现多视角检查
   • 新增VA.PerformValidationWithoutCAA方法分离验证逻辑
   • 通过特性标志控制流程切换

3. 架构简化方案：将所有CAA检查移至证书颁发阶段，完全消除验证与颁发间的时间差风险。

实施路径选择

经过深入讨论，团队首先实施了#7061/#7221中的基础增强方案，为VA.IsCAAValid添加了远程视角支持。随后通过#7870进行了更彻底的重构：

1. 创建独立的"ValidateChallenge"和"CheckCAA" RPC服务
2. 将逻辑控制完全上移至RA(Registration Authority)层
3. 移除了旧的PerformValidation和IsCAAValid方法

这种架构调整带来了两个显著优势：

• 代码复杂度显著降低
• 为未来采用"短时效授权"或"颁发时CAA检查"策略提供了灵活性

性能与可靠性考量

在方案讨论中，团队特别关注了两种潜在影响：

1. 同步延迟：将CAA检查移至颁发阶段可能导致最终化接口(/acme/finalize/)出现可感知的延迟，因为需要同步执行DNS查询。

2. 失败率变化：原本只有少量重用旧授权的请求会触发CAA重新检查，改动后所有请求都将执行该操作，可能影响整体成功率。

实际数据表明，由于现代DNS基础设施的可靠性提升，这些担忧在实测中并未成为实质性问题。

最佳实践启示

这一技术演进过程为证书系统设计提供了重要参考：

1. 协议合规性：实现应严格遵循标准规范要求，特别是时间敏感的安全检查。

2. 视角多样性：安全关键检查应从多个网络视角进行验证，避免单点判断失误。

3. 架构清晰性：通过职责分离使系统组件更专注、更可维护。

目前，新架构已准备就绪，只需在生产环境中启用相应标志即可完成全面切换。这一改进使Let's Encrypt的基础设施更加健壮，更好地保障了证书颁发的安全性和可靠性。