[aws-certificatemanager] DnsValidatedCertificate support for separate hosted zones and accounts

Hello there!

Currently, DnsValidatedCertificate construct only allows using a single hosted zone. If the ACM certificate I’m creating needs SANs that belong to multiple hosted zones, stack creation fails.

DnsValidatedCertificate should allow skipping/waiting for SANs that belong to different hosted zones. For example, it would update correct DNS records in the target hosted zone, and display validation records for the zones it doesn’t have access to, while halting stack update.

Use Case

I’m working on a project that involves separate AWS accounts per region/stage. My ‘root’ AWS account contains the hosted zone for the root domain (example.com), while regional accounts contain hosted zones for sub-domains (us-west-2.example.com, us-east-1.example.com).

While I can work around hosted zones creation (and the necessity to copy NS records from us-west-2.example.com to example.com), doing the same for ACM certificates is quite difficult.

For example, I need to create a certificate for us-west-2.example.com, with a SAN record for example.com.

DnsValidatedCertificate doesn’t allow me to do that, since it tries to update us-west-2.example.com’s DNS with 2 validation records, and the one for example.com doesn’t belong there.

Certificate also doesn’t allow me to do that, since it waits for DNS records to be updated : one for example.com and one for us-west-2.example.com. The problem here is that both hosted zone and certificate for us-west-2.example.com are in the same stack, so I have a bit of a chicken/egg problem.

---

This is a 🚀 Feature Request

[skulljoi]

I need this feature too add a possibility for acm.Certificate to add property region will be great! or making DnsValidatedCertificate support subjectAlternativeNames and validation from differents dns hosted zone

[aripalo]

I agree with what @Tanuel said, that this issue is not just about cross-account.

It’s quite common to see zone delegation even within single account, since it keeps things a bit more organized, but at the same time there are use cases to having ACM certificate that targets multiple zones.

Then again, having to deploy CloudFront certificate separately in different stack to different region (us-east-1) makes things unnecessarily complicated - compared to having a certificate construct that can deploy to us-east-1 from another region.

Having support for setting the region in certificatemanager.Certificate construct would solve these issues.