AWS ACM 证书未验证

AWS ACM certificate not validating

在开始之前,让我先声明一下,我通读了附录中的所有堆栈溢出帖子和资源,但找不到解决我的问题的方法。

我正在尝试通过 Route53AWS 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)
    }

如您所见,它创建了一个 public 托管区域、一个 acm 证书甚至验证记录。这里的问题是证书停留在“Pending Validation”状态大约 48 小时。

一些细节:

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.comdig 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 结尾有一个 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

}

创建一个混乱的状态文件,但它有效

您的 Terraform 创建的一切都很好,但是当您在 AWS 中创建一个新区域时,您需要在 ROOT DNS 面板上添加名称服务器(很可能是您购买域名的地方 mycompany.com)。

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

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

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

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

您不能通过添加记录来打破域托管区域,您只会打破 link 与子域托管区域。

为了举例说明,假设您有一个域 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 托管区域时创建的。在您需要获取名称服务器并将它们添加到您的域名提供商之后。通过这种方式,您 link AWS 的域并且它知道它是有效的。

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

所有这些都需要在创建 ACM 证书之前完成,原因是 ACM 具有域验证,它会尝试为您的有效域或子域创建记录。如果您的域或子域未 link 加入有效域,则 acm 将抛出错误。