CAA记录、CAA策略、CAA检测分别是什么？

　　搞网络安全的朋友，或者负责公司域名管理的运维，多半遇到过这种情况：明明没用某家CA的证书，证书却突然出现在域名名下；或者申请证书时被CA告知“CAA检查不通过”，莫名其妙卡了好几天。这些问题的根源，都跟CAA的三个核心概念脱不了关系——CAA记录、CAA策略和CAA检测。很多人把这几个词混着用，但它们其实是不同层面的东西。

　　一、CAA记录：写在DNS里的“白名单”

　　CAA记录的全称是Certificate Authority Authorization record，证书颁发机构授权记录。它是存在DNS里的一条文本记录，作用非常简单：告诉全世界的CA机构，谁有资格给我的域名签发SSL证书，谁没资格。

　　默认情况下，全球上百家CA机构，只要通过了域名验证(比如验证你拥有域名的控制权)，就可以为你域名签发证书。这意味着，如果这上百家里有任何一家的验证流程出了漏洞，你的域名就有可能被错误地签发证书。CAA相当于在你家门口贴了一张“白名单”，不在名单上的CA一律不准进。

　　从2017年9月8日起，所有CA机构在签发证书前都必须强制检查CAA记录，这是一个行业硬性规定，不是可选项。

　　CAA记录长什么样? 格式是三段式：[flag] [tag] [value]。

　　三个字段的含义分别是：

　　flag(标志位)：控制CA遇到不识别的指令时该怎么处理。取值为0时，CA会忽略它不认识的指令；取值为128时，CA必须理解这条指令，否则就拒绝签发证书。

　　tag(指令类型)：告诉CA这条记录在授权什么。常见的有issue(授权普通证书)、issuewild(授权通配符证书)和iodef(设置违规通知地址)。

　　value(授权对象)：具体授权给哪个CA，格式是CA的域名(比如“sectigo.com”)，或者是接收违规通知的邮箱地址。

　　最常见的配置示例包括：

　　0 issue "sectigo.com"：只允许Sectigo签发普通证书

　　0 issuewild "digicert.com"：只允许DigiCert签发通配符证书

　　0 iodef "mailto:admin@你的域名.com"：违规尝试时发邮件通知你

　　CAA记录放在哪? CAA记录遵循“从近到远”原则——CA会从你要申请证书的域名开始，逐级往上查找，找到第一条CAA记录就停下来。子域名的CAA记录会覆盖父域名的。如果域名设置了CNAME，CA会直接去查CNAME目标域名的CAA记录，因为CNAME优先级最高，不能和其他记录共存。

　　如果没设置CAA记录呢? 任何CA都可以为这个域名签发证书——相当于你家门口没贴白名单，全城锁匠都能配你家钥匙。

　　二、CAA策略：你定的“门禁规则”

　　CAA策略解决的是“我到底该怎么写这个白名单”的问题。

　　CAA记录本身只是一条数据，但围绕这条数据，你还需要做一系列决策，这些决策合在一起就是你的CAA策略。说白了，策略就是你的“门禁规则”：

　　1. 授权哪些CA?

　　只授权一家(比如只用Let's Encrypt免费证书)

　　授权多家(比如Sectigo + DigiCert + GlobalSign)

　　通配符证书和非通配符证书分别授权给不同的CA

　　2. 要不要区分普通证书和通配符证书?

　　如果只配了issue没配issuewild，CA会沿用issue的授权规则。只有当你需要分开授权时，才需要单独配issuewild。

　　3. 违规了怎么通知?

　　配不配iodef来收警报?配邮箱还是配HTTP端点?

　　4. 子域名怎么管?

　　统一在根域名配，所有子域名共用一份白名单

　　在关键子域名单独配，覆盖根域名的规则

　　制定策略时需要考虑的现实因素：

　　业务需求：如果你的公司同时用多家CA的证书(比如腾讯云证书用于主站、Let's Encrypt用于测试环境)，CAA记录里就要把这几家都授权进去

　　CA变更风险：如果某天决定从Sectigo换到DigiCert，需要先把新的CAA记录添上，等生效后再去申请新证书——顺序搞反了证书会下不来

　　回滚预案：配CAA记录之前，先把现有的DNS配置完整备份一份。万一配错了导致证书续不了期，还能快速回滚

　　三、CAA检测：CA和域名所有者都在查的“通行证”

　　CAA检测说的是两个方向的事：CA在签发证书前做的强制性检查，以及域名所有者自己做的验证性检查。

　　CA端的强制性检查

　　这是CAA机制的核心执行环节。2017年3月，CA/Browser Forum通过187号提案，要求所有CA机构从2017年9月8日起执行CAA强制性检查。

　　具体流程是：你向某家CA申请SSL证书，CA收到请求后，首先会去查询你域名的DNS，看有没有CAA记录：

　　如果没有CAA记录，CA认为没有设置限制，可以正常签发。

　　如果有CAA记录且授权了这家CA，正常签发。

　　如果有CAA记录但没授权这家CA，拒绝签发。

　　如果CAA检查不通过，证书申请会卡住，你可能收到类似“CAA validation failed”的报错。

　　域名所有者的自查验证

　　作为域名持有者，你自己也需要会做CAA检测——验证CAA记录是否生效、是否写对了。

　　方法很简单，用dig命令，如果返回了你配置的记录内容，说明生效了。如果什么也没返回，可能是记录没配好、TTL还没过期，或者DNS服务商不支持CAA。

　　还有一些在线工具可以做CAA查询，输入域名直接看结果。

　　另外，如果要排查“为什么证书申请被拒绝”的问题，建议查询父域名的CAA记录——CA是逐级往上查的，有时候问题出在父域而不是你申请的那个子域名上。

　　三者的关系和协作流程

　　把三个概念串起来看，就很好理解了：

　　CAA记录的本质是DNS里的文本数据，写明白名单，由域名所有者负责添加，在DNS配置阶段完成。

　　CAA策略的本质是围绕CAA记录的管理决策(比如授权谁、怎么通知等)，同样由域名所有者负责制定，在配记录之前就要想清楚。

　　CAA检测的本质是CA的强制检查加上域名所有者的自行验证，由CA机构和域名所有者共同执行，发生在每次申请证书时以及配置记录后的验证环节。

　　协作流程是：你先制定CAA策略(想清楚要授权哪些CA)→ 按策略添加CAA记录到DNS → 自己用dig做CAA检测确认生效 → 下次申请证书时，CA机构做强制性CAA检测，通过了才下发证书。

　　常见问题快速排查

　　1. 证书申请被拒绝，提示CAA相关问题

　　用dig 你的域名 CAA查一下现有的CAA记录，看你申请的CA在不在白名单里。同时检查父域名有没有设置更严格的CAA限制——CA是逐级往上查的，子域名的记录覆盖父域名，但父域名的限制也会影响子域名。如果最近刚改过CAA记录，需要等TTL过期(DNS缓存刷新)后再试。

　　2. 同一个域名配了多条CAA记录，CA怎么处理?

　　多条issue记录是“并集”关系——只要申请证书的CA匹配其中任何一条，就通过。iodef是独立的通知配置，跟授权逻辑互不干扰。

　　3. 服务商说“不支持CAA记录”

　　根据RFC 1035标准，DNS对于无法识别的查询类型(包括CAA)应该返回NOERROR而不是NOTIMP。如果你的DNS服务商对CAA查询返回NOTIMP或SERVFAIL，说明他们实现有缺陷，考虑换DNS托管商。

　　4. 子域名单独配了CAA，但CA似乎没按它执行?

　　检查子域名是否设置了CNAME。如果子域名有CNAME指向其他域名，CA会直接去查CNAME目标的CAA记录，不再查子域名本身。

　　总结一句：CAA记录是写在DNS里的“白名单”数据，CAA策略是围绕这条数据的决策和管理规则，CAA检测是CA签发证书时的强制执行动作以及你自己的验证手段。三个概念分清楚了，以后遇到CAA相关的问题，排查思路会清晰很多。