每个人都可以，
拥有SSL证书

2026年7月18日，一份行业解读把CA/B论坛5月通过的SC-098v2提案推到台前。

提案内容不复杂：2027年3月起，所有证书颁发机构必须支持ACME CAA扩展，也就是RFC 8657。

乍一看又是合规升级，细看会发现，这次补的是CAA记录多年的一个口子。

CAA记录大家不陌生。2017年CA/B论坛就要求CA签发证书前必须检查域名的CAA记录，让域名持有者能声明“只允许这几个CA给我发证书”。

这很好，但有个盲区：CAA只限制了CA的身份，没限制验证方式。如果某个被允许的CA支持多种验证方法，攻击者还是可能通过更弱的验证通道拿到合法证书。比如你指定只信任某家CA，但这CA既支持DNS验证也支持文件验证，攻击者如果通过某种手段完成文件验证，一样能搞到证书。

RFC 8657把这个口子堵上了。它在CAA记录里增加了验证方法参数，允许你这样写：

example.com. CAA 0 issue "ca.example.net; validation-methods=dns-01,http-01"

意思很直接——我允许ca.example.net给我发证，但只接受用dns-01或http-01这两种方法验证，别的不认。CA必须执行这个约束，否则违规。

这就是所谓的ACME CAA扩展。ACME协议本身负责自动化证书申请和验证，现在通过CAA记录把验证方式也纳入域名持有者的控制范围，整个信任链条才算真正闭环。

从实操角度看，这条记录生效后，哪怕同一个CA底下有员工被钓鱼、内部流程被绕过，想偷偷用邮件验证之类的方式签发证书，CA的系统也会直接拒绝。不是CA信不过，是多了一层审计式的硬兜底。

证书管理的野路子，会被这条记录逼出原形

不少中小企业甚至大厂的边缘业务，证书申请还停留在“谁需要谁去某个CA后台手动点”的阶段。CAA记录可能根本没配。验证方法默认全开。表面上证书是自动续的，实际控制权并不完全在自己手里。

2027年3月之后，如果CAA记录不加上验证方法限定，要么CA因合规要求直接拒签，要么虽然签了但审计时被记一笔违规。

运维这边如果没提前把CAA记录配合ACME自动化管起来，出问题就是半夜告警连环call。

自动化证书管理本来不是什么新概念。ACME客户端负责和CA对话，自动完成域名验证、证书签发、部署重载，一条龙。

但以前不少团队觉得CAA记录配条issue就够了，验证方法限不限定无所谓。新规等于明确告诉你：不可以无所谓了。

现在要做的，就是在自动化管线里，把CAA记录精细到验证方法级别。

如果已经在用支持ACME协议的客户端，这事就很自然了。CA会根据CAA记录里的验证方法限制，只执行你允许的挑战类型，你只需要提前把CAA记录配好，剩下的申请、验证、部署全自动跑。

留给运维的时间窗口，其实就几个月

从适配工作量看，这不算一个重活。像lcjmSSL这类平台，底层对接的是Let's Encrypt、Google Trust Services、ZeroSSL这些早已支持ACME CAA扩展的CA，提供简洁的API，一条命令或者几行脚本就能把多域名、泛域名甚至IP证书的自动管理串起来，不用自己折腾不同CA的接口差异。核心价值是把RFC 8657的合规要求消化在申请环节，让CAA记录的验证方法约束和自动化续期形成闭环。

但麻烦在存量。很多域名的CAA记录配完就没再动过，各业务线散落的证书申请入口也需要收拢。建议现在就做一件事：拿几个核心域名dig一下CAA记录，看返回里有没有validation-methods字段。空的，或者压根没配CAA，都意味着有新工作要排进迭代了。

别等到CA强制合规那天，业务中断再排查。配一条带验证方法的CAA记录，加上启用ACME自动续期，最多半天工作量。半天换半夜不被叫醒，很划算。