ACM DNS验证卡住导致SSL证书验证超时失败求助

核心问题定位方向 #

从你提到的CLI查询域名服务器无结果来看，域名的DNS解析链存在异常，这是导致ACM验证超时失败的核心原因，可从以下环节逐一排查：

1. 确认域名NS记录指向Route53托管区 #

• 登录域名注册商后台，检查域名的NS记录是否与Route53公共托管区的NS服务器地址完全匹配：
  • 在Route53托管区详情页复制4条完整的NS记录值（注意末尾的.不能省略），确保注册商后台的NS记录和这些值完全一致。
• 若注册商的NS记录未更新或匹配不全，外界无法通过Route53解析你的域名，ACM的验证请求自然找不到你添加的CNAME记录。

2. 验证CNAME记录的准确性 #

• 严格对比ACM证书详情中要求的验证CNAME记录，与你在Route53创建的RecordSet是否完全一致：
  • Name字段：必须和ACM给出的验证域名完全匹配（例如_42fb819b92f98e5ef699548b8d5a52df.watsky1337.link.，注意末尾的.）
  • ResourceRecords：目标域名必须和ACM提供的完全一致，包括末尾的.
  • 可在本地用命令测试记录是否生效：

    dig _42fb819b92f98e5ef699548b8d5a52df.watsky1337.link CNAME
    

    若返回空结果，说明CNAME记录未对外生效，大概率是NS记录配置错误导致。

3. 检查CloudFormation模板配置 #

• 若需同时验证主域名watsky1337.link和泛域名*.watsky1337.link，需在证书模板中添加SubjectAlternativeNames字段，仅填*.watsky1337.link只会生成泛域名的验证记录：

  {"Resources":{"MyCertificate":{"Type":"AWS::CertificateManager::Certificate","Properties":{"DomainName":"watsky1337.link","SubjectAlternativeNames":["*.watsky1337.link"],"ValidationMethod":"DNS"}}}}
  

• 确认Route53 RecordSet的HostedZoneId为你创建的公共托管区ID，避免误填私有托管区或其他区域ID。

4. 等待DNS传播完成 #

• NS记录更新后，全球DNS传播通常需要1-24小时，可通过多节点DNS查询工具确认域名NS记录已生效。
• 传播完成后，在ACM控制台重新触发证书验证操作。

内容的提问来源于stack exchange，提问作者Apoorv Patne