(aws-certificatemanager): DNS Validation fails when alternates are in different hosted zones

Although SSL Certificates may contain alternate subject domains with different hosted zones and it is possible to create such certificates via Web Console, aws command line and, in fact, CDK (using the Certificate class), it is not possible to do this with DnsValidatedCertificate. The certificate is, in fact, actually created. However, the CDK management code triggers an error causing a rollback of the Stack creation or update process despite the successful creation of the certificate.

Reproduction Steps

const hzMap = { "www.example.com": "example.com", "www.example.net": "example.net" };

cert = new acm.DnsValidatedCertificate(this, "cert", {
  domainName: "www.example.com",
  hostedZone: "example.com",
  validation: acm.CertificateValidation.fromDnsMultiZone(hzMap),
  region: 'us-east-1',                       // Required for CloudFront
  subjectAlternativeNames: domains,
});

I coded a stack that triggers the bug. It contains two options:

1. Triggers the bug
2. Successfully builds a Certificate in local region using two hosted zones, but cannot select region.

github repo

What did you expect to happen?

I expected that a Certificate containing the two different domains each existing in two separate hosted zones would have resulted in a Certificate created in the region ‘us-east-1’. Note, the current region for this was not ‘us-east-1’. Then, I would have expected the Stack creation process to have continued successfully to completion.

What actually happened?

A Certificate was created in the ‘us-east-1’ region. Then, upon an attempt to create A Records, the record for www.example.net was attempted to be created within the hosted zone for example.com. This caused a failure (example.com cannot hold a record for example.net) which triggered a rollback of the stack creation. So, the Certificate was created successfully, but the A record entries were not.

Environment

• CDK CLI Version : 1.109.0 (build c647e38)
• Framework Version: 1.109.0
• Node.js Version: v14.17.0
• OS : macOS 10.15.7 (19H524)
• Language (Version): TypeScript (3.9.7)

Other

Note: it is possible to create a Certificate with different hosted zones using the AWS tools and UI. The Web console, the command line tool and CDK’s acm.Certificate() method all allow it. Note, in the case of the latter, it looks like the code (if I have the correct file: lambda handler) uses the sdk call acm.requestCertificate (line 92), which according to the documentation allows SubjectAlternativeNames in different hosted zones (www.example.net). Given this and the fact that I can see the certificate continues to exist in the ‘us-east-1’ region even after rollback, I’m fairly certain that the call to requestCertificate succeeds. Therefore, the problem is almost certainly further down in the code.

Looking lower, Line 146 initiates a change batch call into Route 53 to create the A Records passing the hosted zone ID at Line 163. It uses an array of records collected at Line 130. I believe it is this batch change call that’s failing as that’s indicated by the error I’m seeing. I don’t have a copy of the command line error as the stack creation process erases it, but it mentions something about not allowed to create example.net in example.com hosted zone. This would fit with a fixed hosted zone (Line 163) and varied hosted zones required for the A records.

I think this batch change needs to be broken up into separate hosted zones depending upon the zone matching the domain(s).

---

This is 🐛 Bug Report

[ckifer]

+1 Just ran into the last paragraph above from @flavioleggio. We have a stack not in us-east-1 that needs a certificate created in us-east-1. Can’t use DnsValidatedCertificate because of the above issue and can’t use Certificate because the cert needs to be in us-east-1 to associate with a Cloudfront distro.

[codeedog]

In case my original filing was murky, the entire point of the bug is that certificate creation for multiple apex hosted zones (e.g. example.net and example.com) doesn’t work from non us-east-1 regions and the only reason the certificate is being created in the remote us-east-1 region is due to Amazon’s runtime deployment requirement that the cert live in that specific us-east-1 region.