Playing in the SANdbox: Subject Alternate Names on ACM Certificates in CloudFormation

Depending on your view, the speed at which AWS updates and changes can either be a complete nightmare or something that keeps you coming into work every day. Luckily for me, I see it as the latter.

Constant AWS updates means every time I come back to revisit a problem, or I’m surfing the documentation around CloudFormation there’s always a new way to solve something or a different and better way to do things.

When I first started tackling ACM certificates in CloudFormation you couldn’t specify Subject Alternate Names as part of the request – which left you creating a separate certificate for every subdomain you need a certificate to cover. Luckily back in the 70’s Larry Tesler┬áinvented Copy & Paste so it wasn’t too big a deal…at least until you run into the maximum number of certificates you can request in a year (which thankfully was increased from when I first started doing ACM requests in CloudFormation so you shouldn’t realistically hit that limit).

Now that Subject Alternate Names (SANs) are supported this simplifies my CloudFormation quite a bit, but it gets a bit tricky for doing the certificate approvals since I’m going to be adding subdomains and I need the certificate approval to come to an email address domain that actually exists.

In our case, mitel.io is the top level domain and I have email forwarding on for the three email addresses that ACM will send the request to:

  • admin@mitel.io
  • administrator@mitel.io
  • webmaster@mitel.io

A simple certificate request with no SANs and no subdomains looks like the following

If I create a subject alternate name that has a subdomain however (like server.example.mitel.io) it’s going to send emails to @example.mitel.io, and those addresses just simply don’t exist.

To save the major headache of maintaining an SES forwarder and configuration for a bunch of subdomains, we’re going to add a validation domain for each SAN. This is achieved using the DomainValidationOptions property.

We can see we’ve added a DomainValidationOptions object for each one of our SANs that lives in a different subdomain. This instructs ACM to send the validation email to an @mitel.io address instead of the @example.mitel.io or @example2.mitel.io domain.

Of course, the AWS documentation is extremely comprehensive on this CloudFormation resource type so it’s worth giving it a once over for a deep understanding of the available settings for domain validation.

There is a limit of 10 domains on a single ACM certificate, which is probably okay since you can have 100 certificates in an account (which is available to increase with a support ticket).

That’s it for this week!

Cheers,
James.