AWS ACM 证书未验证

Question

在开始之前，让我说，我仔细阅读了附录中的所有堆栈溢出帖子和资源，但找不到解决问题的方法。

我正在尝试通过Route53 和AWS Certificate Manager 创建、验证和连接子域。子域是challenge.sre.mycompany.com。

terraform 计划如下所示：

# module.project_challenge.module.challenge-certificate.aws_acm_certificate.cert will be created
  + resource "aws_acm_certificate" "cert" {
      + arn                       = (known after apply)
      + domain_name               = "challenge.sre.mycompany.com"
      + domain_validation_options = [
          + {
              + domain_name           = "challenge.sre.mycompany.com"
              + resource_record_name  = (known after apply)
              + resource_record_type  = (known after apply)
              + resource_record_value = (known after apply)
            },
        ]
      + id                        = (known after apply)
      + status                    = (known after apply)
      + subject_alternative_names = (known after apply)
      + tags_all                  = (known after apply)
      + validation_emails         = (known after apply)
      + validation_method         = "DNS"
    }

  # module.project_challenge.module.challenge-certificate.aws_acm_certificate_validation.cert will be created
  + resource "aws_acm_certificate_validation" "cert" {
      + certificate_arn         = (known after apply)
      + id                      = (known after apply)
      + validation_record_fqdns = (known after apply)
    }

  # module.project_challenge.module.challenge-certificate.aws_route53_record.cert["challenge.sre.mycompany.com"] will be created
  + resource "aws_route53_record" "cert" {
      + allow_overwrite = true
      + fqdn            = (known after apply)
      + id              = (known after apply)
      + name            = (known after apply)
      + records         = (known after apply)
      + ttl             = 60
      + type            = (known after apply)
      + zone_id         = (known after apply)
    }

  # module.project_challenge.module.vpc.aws_route53_zone.public will be created
  + resource "aws_route53_zone" "public" {
      + arn           = (known after apply)
      + comment       = "Managed by Terraform"
      + force_destroy = false
      + id            = (known after apply)
      + name          = "sre.mycompany.com"
      + name_servers  = (known after apply)
      + tags_all      = (known after apply)
      + zone_id       = (known after apply)
    }

如您所见，它创建了一个公共托管区域、一个 acm 证书甚至是验证记录。这里的问题是证书在“等待验证”上停留了大约 48 小时。

一些细节：

• 该域是通过我们的生产帐户注册的，为此我正在使用我们的开发帐户。
• 两个账户都在同一个 AWS 组织中（如果这很重要）
• Terraform 使用以下属性创建了一个公共托管区域 sre.mycompany.com：

sre.mycompany.com   NS Records: 
ns-001.awsdns-01.com.
ns-002.awsdns-02.net.
ns-003.awsdns-03.co.uk.
ns-004.awsdns-04.org.

sre.mycompany.com   SOA Simple  Record:
ns-001.awsdns-01.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

CNAME   Simple  Record
_g938534f3gfe03832h34.challenge.sre.mycompany.com   _89432htieh4934hw043f.tkfpekghn.acm-validations.aws.

显然真实值被混淆了*

当我 dig sre.mycompany.com 或 dig challenge.sre.mycompany.com 我得到：

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16577
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

当我只挖掘mycompany.com 时，我得到：

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61857
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mycompany.com.     IN  A

;; ANSWER SECTION:
mycompany.com.  300 IN  A   <some-ip-hidden>

;; AUTHORITY SECTION:
mycompany.com.  169554  IN  NS  ns-555.awsdns-55.com.
mycompany.com.  169554  IN  NS  ns-666.awsdns-66.net.
mycompany.com.  169554  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169554  IN  NS  ns-888.awsdns-88.co.uk.

请注意，这里的名称服务器与我在 terraform 创建的托管区域的控制台中看到的不同（滚动到 ns-001.awsdns-01.com. 等上方）

我似乎无法从我的终端获取 CNAME 记录。

另一方面，在 AWS 中，一切似乎都运行良好。当我去：

Route 53> Hosted zones > Test Record我确实得到了 CNAME 记录的值：

Route 53 返回的响应 Route 53 的响应基于以下选项。

托管区域： sre.mycompany.com 记录名称： _g938534f3gfe03832h34.challenge。

记录类型： CNAME DNS 响应代码： 无错误 协议： UDP Route 53 返回的响应： _89432htieh4934hw043f.tkfpekghn.acm-validations.aws。

最后如果我，响应是：

;; Received 888 bytes from <some-ip-hidden>#53(ns-666.awsdns-66.net) in 3 ms
mycompany.com.  169201  IN  NS  ns-666.awsdns-66.net.
mycompany.com.  169201  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169201  IN  NS  ns-888.awsdns-88.co.uk.
mycompany.com.  169201  IN  NS  ns-555.awsdns-55.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 888 bytes from <some-ip-hidden>#53(ns-888.awsdns-88.co.uk) in 4 ms

mycompany.com.  169201  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169201  IN  NS  ns-666.awsdns-66.net.
mycompany.com.  169201  IN  NS  ns-888.awsdns-88.co.uk.
mycompany.com.  169201  IN  NS  ns-555.awsdns-55.com.
;; BAD (HORIZONTAL) REFERRAL

;; Received 888 bytes from <some-ip-hidden>#53(ns-555.awsdns-55.com) in 4 ms

mycompany.com.  169201  IN  NS  ns-666.awsdns-66.net.
mycompany.com.  169201  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169201  IN  NS  ns-555.awsdns-55.com.
mycompany.com.  169201  IN  NS  ns-888.awsdns-88.co.uk.
;; BAD (HORIZONTAL) REFERRAL
;; Received 888 bytes from <some-ip-hidden>#53(ns-888.awsdns-88.co.uk) in 4 ms

mycompany.com.  169201  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169201  IN  NS  ns-666.awsdns-66.net.
mycompany.com.  169201  IN  NS  ns-888.awsdns-88.co.uk.
mycompany.com.  169201  IN  NS  ns-555.awsdns-55.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 888 bytes from <some-ip-hidden>#53(ns-777.awsdns-77.org) in 5 ms

mycompany.com.  169201  IN  NS  ns-777.awsdns-77.org.
mycompany.com.  169201  IN  NS  ns-888.awsdns-88.co.uk.
mycompany.com.  169201  IN  NS  ns-555.awsdns-55.com.
mycompany.com.  169201  IN  NS  ns-666.awsdns-66.net.
;; BAD (HORIZONTAL) REFERRAL

要点：

• 我无法通过终端的任何命令获取 CNAME
• 证书未验证

---

附录

• Certificate in Pending state in AWS Certificate Manager
• Certificate with DNS Validation is stuck in Pending Validation
• AWS ACM certificate state is pending validation and not changing to issues
• My domain is pending validation in AWS Certificate Manager
• AWS ACM Stuck in Pending Validation Unless NS Changed in Domain
• Resolve ACM certificate still pending

Answer 1

您的区域文件中的 CNAME 末尾有一个 mycompany.com。这不是进行 CNAME 的正常方式。应该是：

CNAME   Simple  Record
_g938534f3gfe03832h34.challenge.sre   _89432htieh4934hw043f.tkfpekghn.acm-validations.aws.

如果将 mycompany.com 添加到 CNAME 中，则实际解析地址为_g938534f3gfe03832h34.challenge.sre.mycompany.com.mycompany.com

我发现通过 terraform 将正确的验证记录放入 route53 的唯一方法如下：

resource "aws_route53_record" "cert-verify" {
  for_each = {
    for dvo in aws_acm_certificate.cert_name.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  name = each.value.name
  records = [each.value.record]
  ttl = 60
  type = each.value.type
  zone_id = aws_route53_zone.zone.zone_id

}

生成一个凌乱的状态文件，但它可以工作

Answer 2

您的 terraform 创建的一切都很好，但是当您在 AWS 中创建新区域时，您需要在根 DNS 面板上添加名称服务器（很可能是您购买域 mycompany.com 的位置）。

您需要为要使用的子域（您正在创建的新区域）添加 NS 条目

可以参考这篇文章https://webmasters.stackexchange.com/questions/93897/can-i-use-different-nameservers-for-different-subdomains

Answer 3

当您有多个用于域和子域的 route53 托管区域时，您需要将它们链接在一起。

这可以通过在域托管区域中添加子域名服务器来完成。

您无法通过添加记录来破坏域托管区域，您只会破坏与子域托管区域的链接。

举个例子来说明一下，假设您有一个域 route53 托管区域 mycomany.gr

Record Name	Type	Value
mycomany.gr	NS	ns-xxxx.org ns-xxx.uk
sre.mycompany.com	NS	ns-yyy.org ns-yyy.uk

第一行是在您创建 route53 托管区域时创建的。在您需要获取名称服务器并将它们添加到您的域提供商之后。通过这种方式，您将域与 AWS 链接起来，它知道它的有效性。

创建子域 route53 托管区域 (sre.mycompany.com) 后，您需要手动添加第二行。名称服务器现在是 route53 子域为您创建的名称服务器。通过这种方式，您可以对 route53 说此域 (mycompany.com) 拥有此子域 (sre.mycompany.com)。

所有这些事情都需要在创建 ACM 证书之前完成，原因是 ACM 具有域验证，它试图为您的有效域或子域创建记录。如果您的域或子域未链接到有效域，acm 将抛出错误。