把域名接入 CDN 后，控制台已经显示验证通过，托管证书却一直签发失败。这时继续重填验证记录，往往解决不了问题。证书机构还要检查 CAA，确认自己是否获准为这个域名签发证书。AWS ACM 官方文档也列出了“验证成功后仍出现 CAA 错误”的情况。[1]
本文面向管理域名解析和 CDN 托管证书的网站运维人员。先确认签发机构和失败阶段，再查 CAA、CNAME 与 DNS 响应，最后做范围明确的修改。命令使用示例域名；执行时换成自己的域名。本文依据官方文档整理，未对生产域名进行变更或签发测试。
确认失败发生在哪一步
网站能解析、域名验证通过、证书签发成功、边缘节点已经部署证书，分别对应不同的检查。排查前保存完整错误提示、证书订单状态、申请的全部域名，以及平台要求的验证方式。
如果控制台显示验证待完成，就检查它给出的 TXT、CNAME 或 HTTP 文件要求。若错误明确包含 CAA、unauthorized issuer，就查签发授权。若证书已经签出而浏览器仍报错，再检查域名覆盖范围、证书链和 CDN 部署状态。
同时确认平台实际使用的 CA 及其 CAA 标识。CDN 品牌名称不能直接当成 CAA 的授权值；平台可能使用不同的证书机构。下文的 letsencrypt.org 只用于说明 Let’s Encrypt 的规则，不代表 CloudFlew 或其他 CDN 的默认签发机构。[2]
用完整 DNS 响应检查 CAA
以下命令适用于已安装 dig 的 Linux、macOS 或 WSL 环境，均为只读查询。第一轮保留响应状态、ANSWER 和 AUTHORITY 区，不只看 +short 的结果。
dig www.example.com CAA dig www.example.com CNAME dig example.com CAA dig example.com NS
查看 status、返回记录的所属域名和 TTL。NOERROR 且没有 CAA 答案，与 SERVFAIL、REFUSED 或超时，需要分别处理。查询失败时不能据此认定“域名没有限制”。[2]
没有 CNAME 的简单场景中，证书机构从申请域名开始查 CAA；没有记录就逐级查询父域，直到找到第一组有效记录，或抵达根。子域自己的 CAA 记录集会结束向上搜索，父域记录不会自动与它合并。[3]
例如，www.example.com 没有 CAA，example.com 配置了 issue，该父域策略就可能影响 www.example.com 的签发。一个证书订单包含多个域名时，要逐个检查，不能只看主域。
CNAME 会改变查询结果
CAA 查询会追踪 CNAME 别名。若 www.example.com 指向 CDN 提供的主机名，返回答案可能来自那个目标；只检查自己 DNS 控制台里的根域记录，会漏掉这段查询。[2][3]
dig www.example.com CNAME dig www.example.com CAA # 将下方占位主机名替换为上一条命令得到的实际 CNAME 目标 dig actual-cdn-target.example.net CAA
RFC 8659 的查找算法可以拆开理解：每次对当前名字查 CAA，都按 DNS 规则追踪别名；若这一查询没有得到 CAA，再去掉当前名字最左侧的标签，查询其父域。不要把规则简化成“沿着 CNAME 目标的所有父域向上找”。[3]
普通 DNS 配置中，同一主机名的 CNAME 不能与 CAA 等普通记录共存，因此不要直接在已有 CNAME 的 www 上叠加 CAA。若有效限制来自服务商控制的别名目标，需要让服务商核对记录和支持的 CA；修改自己的根域 CAA 未必能解决。[2]
DNS 托管商提供的 ALIAS、ANAME 或 CNAME flattening 有各自的实现方式。排查这些配置时，以实际公开 DNS 答案和托管商文档为准。
看懂 issue 和 issuewild，再决定修改内容
下面是 DNS 区域文件形式的说明示例，不是要求直接写入生产环境。DNS 控制台通常会把主机记录、标记、标签和值拆成不同字段。[2][3]
example.com. 300 IN CAA 0 issue "letsencrypt.org" example.com. 300 IN CAA 0 issuewild "letsencrypt.org"
issue 用来授权签发机构。没有 issuewild 时，issue 也适用于通配符证书；存在 issuewild 时，通配符签发按 issuewild 的授权处理。因此，普通域名签得出来，*.example.com 失败时，要单独检查通配符授权。[2][3]
同类授权可以有多条，允许的 CA 是累加关系。需要补充一个签发机构时，应保留仍在使用的 CA 授权。某条 issue ";" 本身不授权任何机构；如果同组还存在有效的 issue 授权，它不会单独否决那条授权。若相关记录集中只有拒绝授权的条目，则会阻止签发。[3]
值里的参数也可能带来限制。例如 Let’s Encrypt 支持 validationmethods 和 accounturi，分别限制验证方法和 ACME 账户。复制旧记录时，要检查参数是否与当前平台的方式匹配。[2]
删除全部 CAA 会放宽签发限制，也可能掩盖有效记录位于别处的问题。修改前导出相关 DNS 记录，记下原值、TTL 和修改时间；确认所需 CA 后，在实际生效的记录集上做最小改动。回滚时恢复备份值，并重新检查公开 DNS 响应。
SERVFAIL 和超时先交给 DNS 排查
CAA 查询失败，可能是 DNSSEC 验证异常、权威 DNS 不可用、DNS 服务错误处理 CAA 类型，或防火墙丢弃查询。Let’s Encrypt 的文档分别列出了这些情况。[2]
可以对比递归解析器和权威服务器的答案：
dig @1.1.1.1 www.example.com CAA dig @8.8.8.8 www.example.com CAA dig example.com NS # 替换为该 DNS 区域实际使用的权威服务器 dig @ns1.example-dns.net example.com CAA +norecurse
上面的解析器仅用于交叉检查，它们的成功响应不能代表 CA 使用的解析路径也正常。对有 CNAME 的域名，原始域的权威服务器可能只返回别名；目标域的响应还需要另查。如果子域单独委派了 DNS，使用那个子域的权威服务器。
递归解析器报 SERVFAIL、权威查询却能返回记录时，要进一步检查 DNSSEC 和委派链；权威服务器之间答案不同，则核对区域同步和 NS 配置。保留错误输出交给 DNS 服务商定位，避免通过关闭 DNSSEC 来绕过问题。[2]
修改后对比权威答案和递归答案，等待旧 TTL 或负缓存到期。浏览器刷新无法清除证书机构使用的 DNS 缓存；连续提交签发请求也无法让尚未生效的记录提前可见。
域名验证记录要按平台要求检查
CAA 授权正确后，订单仍可能停留在域名验证阶段。对使用 Let’s Encrypt ACME 的场景，DNS-01 使用 _acme-challenge 下的 TXT；HTTP-01 使用指定 HTTP 路径，入口端口为 80，并且不能用于签发通配符证书。Let’s Encrypt 支持对 DNS-01 的挑战名字使用 CNAME 或 NS 委派。[4]
CDN 托管证书也可能要求另一种专用 CNAME。必须照当前订单提供的名字和值核对，业务域名的 CNAME 指向 CDN，并不自动说明证书验证已经满足要求。
# 仅用于平台明确采用 ACME DNS-01 的场景 dig _acme-challenge.example.com TXT dig _acme-challenge.example.com CNAME
CAA 查询的是申请证书的域名；验证记录则证明你对域名的控制。不要把 CAA 写到 _acme-challenge 上来修复业务域名的签发授权，也不要为排查证书而随意删除正在承载流量的业务 CNAME。
修复后按照平台说明触发重试或重新申请。AWS ACM 对其特定 CAA 失败场景要求修改记录后重新请求证书；其他平台的重试方式需要分别确认。[1]
签出来以后，还要确认边缘部署与续期
订单显示签发成功后，确认 CDN 的证书绑定和部署状态，再访问真实域名查看浏览器证书信息。检查 SAN 是否包含访问的主机名、有效期是否符合预期，以及连接是否仍使用旧证书。签发订单成功和访问端已经拿到新证书，需要分别确认。
把证书订单中的域名、实际 CA、有效 CAA 位置、验证方式和变更记录留在运维文档中。对于需要持续保留验证 CNAME 的托管平台，按其续期说明保留记录；ACME DNS-01 的单次挑战 TXT 则由客户端按挑战生命周期管理。不要把两种记录的保留方式混用。
此次签发恢复后，继续监测证书到期时间和自动续期状态。CAA 与验证链路也会影响之后的签发，记录当前配置有助于在更换 CDN、CA 或 DNS 托管商时提前发现冲突。
官方参考资料
资料核验日期：2026 年 10 月 13 日。
[1] AWS Certificate Manager：Certification Authority Authorization (CAA) problems。仅用于 ACM 的明确案例与重试要求。
[2] Let’s Encrypt：Certificate Authority Authorization (CAA)。CAA 配置、别名、签发机构标识和 DNS 错误说明。
[3] RFC 8659：DNS Certification Authority Authorization (CAA) Resource Record。有效记录集查询与授权规则。
[4] Let’s Encrypt：Challenge Types。HTTP-01、DNS-01 及验证委派规则。
