Region UpdateAs of April 2017, Certificate Manager is available in all regions except for Beijing and GovCloud. CloudFront certificates must still be created in us-east-1.
Overnight Amazon Web Services (AWS) released their AWS Certificate Manager (ACM) product which allows customers to automatically provision, deploy and renew SSL certificates on supported AWS resources (at present they are supported on Elastic Load Balancers (ELBs) and CloudFront).
One of the biggest challenges I see in organisations over and over again is how to manage and ensure SSL certificates are renewed. Quite often a single person responsible for a particular web property will leave the company and that certificate won’t be renewed.
Fortunately the ACM product looks after the certificate rotation for you, and best of all it’s available at no extra cost.
Unfortunately ACM managed SSL certificates can only be provisioned on ELBs in us-east-1 (Virginia) however can be used on CloudFront globally. Let’s take a look at how you get started.
Requesting a certificate
To request a certificate you’ll need to login to the console and open the Certificate Manager. You may need to change your region to Virginia, however as mentioned above if you’re deploying to CloudFront it doesn’t matter what region you request the certificate in.
You’ll need to add all the hostnames to the certificate request.
Once you’ve added the hostnames you’ll be given an opportunity to review the request before it’s sent for validation.
Validating a certificate request
Once a certificate is requested an email will be generated to the domain registrant, administrative, and technical contacts requesting verification. A copy of this email will also be sent to pre-determined email addresses at the domain which are admin@, administrator@, hostmaster@, postmaster@, and webmaster@.
Once all hosts in the request are approved the certificate will be issued.
I did find it unusual that a verification request was sent for each hostname under the domain (ie: a request for shaun.net, www.shaun.net and *.shaun.net in the same request generated three verification emails). Generally with SSL CAs multiple hostnames under the one domain name would simply validate ownership of the overall domain.
Updating your CloudFront distribution
If you’ve deployed SSL to a CloudFront distribution before you’ll know that it’s quite easy to do so. All you need to do is edit your distribution and select the appropriate SSL certificate.
You may need to edit other details in the distribution such as the origin protocol policy and the viewer protocol policy to ensure end-to-end encryption or to redirect users from http to https.
Here’s how easy it is to update:
Once your distribution has changed to a deployed state your certificate will be globally available. You can verify this by accessing the site and viewing the certificate information in your browser. Here you can see that it’s issued by am Amazon CA.
As of writing you can also view the information for this site and see what the certificate looks like.
The initial release FAQ makes mention of CLI and API documentation available at http://docs.aws.amazon.com/acm/latest/acm-cli/reference/acm/request-certificate.html and http://docs.aws.amazon.com/acm/latest/acm-api/API_RequestCertificate.html respectively however as of writing these links do not yet work.
When this information is available I’ll review the API and update this post.
I’m a big advocate of protecting endpoints with SSL unless there’s a good reason not to (and it’s been a while since I’ve heard one) so I love this feature. It’s a bit reminiscent of Let’s Encrypt but doesn’t require installing an agent on your server (or running it elsewhere and updating verification content on your site if you wanted to use a certificate with AWS).
I’d like to see the validation features streamlined. Some SSL authorities accept a DNS entry as validation of domain ownership, and if this was acceptable to Amazon Trust Services then I’d like to see seamless integration with Route53 (such as used with AWS Simple Email Service) rather than relying on emails to the domain registrant.
As mentioned above, the other strange issue I found was that a validation email was generated for every hostname in the request. I’d expect this if there were multiple domains, however this doesn’t seem necessary where all hostnames are under the same domain (in this example a request for shaun.net, www.shaun.net and *.shaun.net in one certificate generated three emails).
Once this is available globally there really will be no excuse to operate an endpoint on your AWS infrastructure without SSL protection as the two usual arguments against SSL (cost and management overhead) are removed from the equation here.
While EV certificates are not available, the Amazon Trust documentation makes reference to these and I wouldn’t be surprised to see them made available in the near future.