logo标签列表

AWS ACM证书未通过验证。

amazon-web-servicesterraformamazon-route53terraform-provider-awsamazon-certificate-manager
3
在我开始之前，先声明一下：我已经仔细阅读了附录中的所有Stack Overflow文章和资源，并且无法找到解决我的问题的方法。
我正在尝试通过Route53和AWS证书管理器创建、验证和连接子域名。该子域名是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> 托管区域 > 测试记录 ，我确实得到了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记录
  • 证书无法验证

附录

这个答案对您有帮助吗？https://dev59.com/sbXna4cB1Zd3GeqPSuuU - Ben Whaley
谢谢@BenWhaley，但我似乎找不到解决方案。 - Dimi
1
@Dimitris 要将托管区域与您的实际域名连接起来（我猜它在不同的提供商那里），您需要获取您的托管区域 mycompany.com 的名称服务器，并将它们放到第三方提供商那里。我猜您已经做对了吧？ - bembas
@bembas 我通过dig mycompany.com获取的域名服务器与托管区sre.mycompany.com中显示的不同。我想这确实是问题所在！ 我猜测将托管区中的NS记录更改为从域名dig中获取的记录将使其正常工作。 更改sre.mycompany.com中的NS是否有可能破坏mycompany.com的功能？在子域名的情况下，DNS如何工作让我感到非常困惑。 - Dimi
当您创建托管区域时，Amazon Route 53会分配一个委派集（四个名称服务器的集合）来为您的托管区域提供服务。然后，Route 53在区域内创建一个与您的托管区域同名的名称服务器（NS）记录，列出了分配的四个名称服务器。如果更改此NS记录，则不会更改Route 53分配的名称服务器。有些情况下，您可能需要更改NS记录，例如配置品牌名称服务器。但是，请注意，对NS记录进行不正确的更改可能会导致您的域在互联网上无法使用。 - Dimi
显示剩余10条评论
3个回答
2
这完全有道理，很可能是问题的解决方案。在进行任何实际更改之前，我想确保我正确理解了这一点。“您需要添加要使用的子域的NS条目”，我认为您指的是在我的托管区sre.mycompany.com上自动创建的那些条目？“在ROOT DNS面板上添加名称服务器”，您所说的根DNS面板是指具有mycompany.com的那个面板吗？我理解得对吗？ - Dimi
1
@Dimitris 没错，请尝试这样做，如果有效请告诉我。 - Diego Velez
1
当您有多个route53托管区域用于域名和子域名时，您需要将它们链接在一起。
这可以通过在域托管区域中添加子域名称服务器来完成。
您不能通过添加记录来破坏域托管区域，您只会破坏与子域托管区域的链接。
因此，为了举例说明，假设您有一个mycomany.gr的路由53托管区域。
第一行是创建route53托管区域时创建的。之后，您需要获取名称服务器并将其添加到您的域提供程序。通过这种方式，您将域名与AWS连接起来，并使其有效。
第二行是在创建子域route53托管区域（sre.mycompany.com）之后手动添加的。现在，名称服务器是route53子域为您创建的名称服务器。通过这种方式，您告诉route53此域（mycompany.com）拥有此子域（sre.mycompany.com）。
所有这些都需要在创建ACM证书之前完成，原因是ACM具有域验证，尝试在您的有效域或子域中创建记录。如果您的域或子域未链接到有效域，则ACM会抛出错误。
0

您的区域文件中的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

}

虽然会导致状态文件混乱，但它能够正常工作。

裸域是一个常见的问题，但它不适用于这种情况。 - Dimi
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接