通配符证书带根域后 CAA 拒绝：核对 issue 和 issuewild

在面板里选了通配符证书，DNS 里也有 issuewild letsencrypt.org，申请却返回 CAA record for example.com prevents issuance、urn:ietf:params:acme:error:caa。如果这张证书还包含 example.com，而同一组 CAA 的 issue 明确禁止普通名称签发，两项设置就能解释这次失败。

这适用于 Let’s Encrypt 及遵循 CAA 规则的签发流程。面板如何组合证书名称因产品和版本而异；先查看本次订单，不能仅凭“通配符”按钮判断它只申请了 *.example.com。

看拒绝的是哪个名称

在 ACME 客户端日志或面板任务详情里，找到失败授权对应的域名，再对照订单里的全部名称。*.example.com 和 example.com 是两个不同的名称，通配符不会覆盖根域本身。

如果证书需要同时覆盖它们，两项授权都得通过。DNS-01 的 TXT 验证正确，也不能代替 CAA 的签发许可。错误类型仍是 caa 时，反复重建 TXT 或重启 Web 服务无法改变这项策略。

下面是一组会产生这种区别的示例记录，域名和格式仅作说明：

example.com.  CAA 0 issuewild "letsencrypt.org"
example.com.  CAA 0 issue ";"

issuewild 允许 Let’s Encrypt 签发通配符；issue ";" 没有指定任何获准机构，限制普通名称签发。这组记录不能满足同时包含根域的订单。

不能据此推断“只有 issuewild 就禁止普通证书”。没有任何 issue 限制，与显式写了禁止签发的 issue 是两种情况。issuewild 专门决定通配符许可；没有 issuewild 时，通配符会使用 issue 的规则。

按实际需要调整许可

如果根域和通配符都应由 Let’s Encrypt 签发，可以把普通名称的禁止记录改成允许该机构，例如：

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issuewild "letsencrypt.org"

当两者使用相同许可时，通常只保留 issue "letsencrypt.org" 也能覆盖两类申请。若组织有分别授权的要求，保留两种标签便于表达策略。

修改前保存完整 CAA 记录集、TTL 和原来的限制理由；涉及机构白名单或指定 ACME 账户的策略，需要获得管理该策略的人员授权。不要直接把所有 CAA 删掉。相同标签下的记录是累加许可，新增一条允许记录可能扩大原有授权范围；accounturi、validationmethods 等参数也须按实际账户和验证方式保留。

如果根域不应被授权，就从本次订单移除 example.com，仅申请确实需要的通配符名称。这样证书不能用于根域站点，部署和跳转安排也要对应调整。

面板改完，权威 DNS 还要核对

可在安装了 dig 的设备上查看实际返回值，例如：

dig example.com CAA +short
dig @ns1.example.net example.com CAA +norecurse

第二条中的服务器须替换为该域名实际的权威 DNS。检查各权威服务器是否都返回修改后的记录；面板保存成功，并不表示所有节点与缓存都已经更新。

对普通子域名，还要检查更接近该名称的 CAA 记录及 CNAME 目标。CA 会使用适用位置的策略，根域新记录未必覆盖子域自己的限制。若实际错误是 SERVFAIL 或 DNS 查询超时，应处理 DNS 可用性，不能继续按这组标签冲突解释。

等待记录同步及相关缓存过期后，重新提交预期名称的订单。成功标准是本次所需的每个名称都完成授权，拿到的证书也包含正确名称。需要回退时恢复原记录集；回退会恢复原限制，不会撤销已经签发的证书。