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

1

2

3

4

5

6

"SimpleWebCert":{

"Type":"AWS::CertificateManager::Certificate",

"Properties":{

"DomainName":"server.mitel.io"

}

}

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.

1

2

3

4

5

6

7

8

9

"SANWebCert":{

"Type":"AWS::CertificateManager::Certificate",

"Properties":{

"DomainName":"server.mitel.io",

"SubjectAlternativeNames":[

"server.example.mitel.io"

]

}

}

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.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

"SANWebCert":{

"Type":"AWS::CertificateManager::Certificate",

"Properties":{

"DomainName":"server.mitel.io",

"SubjectAlternativeNames":[

"server.example.mitel.io",

"server2.example2.mitel.io"

],

"DomainValidationOptions":[

{

"DomainName":"server.example.mitel.io",

"ValidationDomain":"mitel.io"

},

{

"DomainName":"server2.example2.mitel.io",

"ValidationDomain":"mitel.io"

}

]

}

}

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).