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
"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.
"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.
"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).
That’s it for this week!
Cheers,
James.