aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.58k stars 3.88k forks source link

[aws-certificatemanager] New DNS validation method not working due to route53 error #9248

Closed stephenwiebe closed 4 years ago

stephenwiebe commented 4 years ago

I saw that there was a new preferred way of creating certificates via DNS validation: https://github.com/aws/aws-cdk/pull/8552. I tried replacing our current DnsValidatedCertificate resources with Certificate with DNS validation method specified for validation, but it doesn't seem to work for me as it gets a route53 error: Service: AmazonRoute53; Status Code: 400; Error Code: InvalidChangeBatch;. After switching back to DnsValidatedCertificate, it starts working again.

Reproduction Steps

This is the DnsValidatedCertificate method that works:

    const externalHostedZone = route53.HostedZone.fromHostedZoneAttributes(this, 'ExternalHostedZone', {
      hostedZoneId: props.externalZoneId,
      zoneName: props.domainName
    });

    this.defaultCertificate = new certificatemanager.DnsValidatedCertificate(this, 'DefaultCertificate', {
      domainName: '*.' + externalHostedZone.zoneName,
      hostedZone: externalHostedZone,
      subjectAlternativeNames: [externalHostedZone.zoneName]
    });

And this doesn't work:

    const externalHostedZone = route53.HostedZone.fromHostedZoneAttributes(this, 'ExternalHostedZone', {
      hostedZoneId: props.externalZoneId,
      zoneName: props.domainName
    });

    this.defaultCertificate = new certificatemanager.Certificate(this, 'DefaultCertificate', {
      domainName: '*.' + externalHostedZone.zoneName,
      validation: certificatemanager.CertificateValidation.fromDns(externalHostedZone),
      subjectAlternativeNames: [externalHostedZone.zoneName]
    });

Error Log

I first see a message that looks like it's attempting the correct DNS record:

Content of DNS Record is: {Name: _64bdf27fde66ffe03781a30f892765aa.shopvox-dev.com.,Type: CNAME,Value: _f747a4bd656f7214046e0c2be79f5c0e.tfmgdnztqk.acm-validations.aws.}

followed by

[The request contains an invalid set of changes for a resource record set 'CNAME _64bdf27fde66ffe03781a30f892765aa.shopvox-dev.com.'] (Service: AmazonRoute53; Status Code: 400; Error Code: InvalidChangeBatch; Request ID: fb78d552-8545-4e05-9869-d7d9a5e6dc1e)

Environment

Other


This is :bug: Bug Report

njlynch commented 4 years ago

Thanks for the bug report, @stephenwiebe!

This looks related to how the DNS validation is handling wildcard domain names. The DNS validation entries for "*.example.com" and "example.com" are the same, and I suspect somewhere in the CloudFormation DNS validation workflow this is causing the issue. I've reproduced the behavior and have a fix (#9291) which seems to address the issue.

Jrodseth commented 3 years ago

I'm experiencing a potential regression of this issue while attempting to create a certificate with both a domainName of example.com and an alternative name of *.example.com on cdk version 1.98.0

Fortunately I have a comprehensive list of subdomains for this stack I can use as a workaround, but I'm curious if others are also experiencing this issue again.

tomyam1 commented 3 years ago

Got here after getting the The request contains an invalid set of changes for a resource record set error from CloudFormation.

After reading https://github.com/aws/aws-cdk/pull/9291 it was clear that I just need to remove the star domain from DomainValidationOptions and then the build was successful

spg commented 3 years ago

I went from using a acm.Certificate to using a acm.DnsValidatedCertificate and this fixed it for me.

chris-bannister-privitar commented 3 years ago

Also hitting this, though it seems to only be an issue when the hosted zone is from HostedZone.fromHostedZoneAttributes as the same codepath works fine when the hosted zone is created by the app which is generating the certificate.

chris-bannister-privitar commented 3 years ago

@spg @antonioortegajr @joaomilho I posted a work around in #15574