For those who followed my original post a year ago on how to get a site up with a static site generator, serverlessly, that is blazing fast, you’re going to need to renew your security certificate soon. This is how that’s done through Amazon Certificate Manager via Let’s Encrypt.
In truth, Amazon’s Certificate Manager (ACM) does a good job of taking something that used to be a painful, nail-biting, horrible experience around changing your web site’s SSL cert and makes it much easier. Especially if you’re running your own domain, ACM combined with the geniuses at Let’s Encrypt, it’s now semi-painless (with a little knowledge) to secure your sites with SSL. It’s not obvious, however, how to change or renew once you’re set up, so we’ll doing the walkthrough.
At this point, the reasons for having your site on
https:// should be obvious. Besides the good hygiene of making traffic secure, your users safer, avoiding surveillance, and making sure you don’t suffer in your organic search rankings (google juice now penalizing non-TLS sites), it can also make your site faster by using https/2. And a faster, better experience for your users makes you look good and is the right thing to do. So, this is how you go about it.
Some pre-conditions on this one for those of you do not have your entire life tied to the Amazon stack, but didn’t follow the tutorial above:
- You are using an external domain and DNS provider (I’m a big fan of DNSimple and have used them for years. I delegate to Route53.)
- You either need to rotate your cert or have gotten a mail from Amazon your cert is expiring
- You are using Cloudfront to edge-cache your site for speed and are hosting on S3 as per the guide I provided
The Story so far:
The robot overlords at Amazon Web Services (AWS) sent you (or are about to send you) an email warning:
Action Required - Your certificate renewal and detailing You have an AWS Certificate Manager (ACM) SSL/TLS certificate in your AWS account that expires on Mmm dd, yyyy at 12:00:00 UTC. That certificate includes the primary domain awesomesauce.com and a total of 1 domains.
Don’t panic. While in the past, such a thing could make even your geekiest sysadmin sweat, while it’s slightly confusing how to wire things up, once you’ve got the cert renewed the actual process itself fairly painless.
And you’ve got some time. My mail landed in my inbox a good 60-ish days before the expiry of my old cert. Since, it’s free and a good 30 minute task you can do between meetings, this should not take too long (I literally did mine while waiting for a CEO call that was late).
If you’re lucky, and your domain provider exposes your email address to everyone through WHOIS, you may even get an email which allows you to automatically renew which should roll the cert over automatically and (apparently) painlessly (esp if you use Route53). This is not the case for most people with more complex online lives these days though, which means you will:
- Need to request a new certificate through ACM
- Validate it via your DNS provider (by creating a CNAME record)
- Repoint Cloudfront to use the new cert
Sounds a bit tricky. It did take me some poking around to puzzle out, so I figured a simple guide for people who had built the same sort of jekyll or gatsby site as I had would be handy for those who is was not transparent for (let’s face it, Amazon can get tricky sometimes. I thought I’d done something very wrong when I was in the wrong region for my cert and Cloudfront compared to the S3 bucket where I keep my actual site.).
Requesting a Cert
This can be done via the command line, but it’s actually easier to log into your Amazon web console.
Log in and figure out which region the certificate that Amazon warned you about is in (I keep all my personal ones in the same region to make tmy life easier though generally use Central Canada or Ireland regions for actual hosted services that require a geo.).
- Get to the ACM section of the AWS admin console.
- Click the
- On the next screen, you are defaulted to picking a
Requst public certificateradio selection so just hit the
Request a certificatebutton.
- Domain Names: Next screen you must pick a domain name. Let’s choose
*.awesomesauce.com(though you could equally pick a fully qualified domain name like
blog.awesomesauce.comif you wanted to have different certs for different domains.).
- Validation Method: Since we’re assuming this did not autorenew via email you’re going to be selected DNS validation.
At this point, Amazon will fire off the request for the certificate and you will almost right away get back a message saying you need to “Create a CNAME record in the DNS configuration for each of the domains listed below.”
It’ll look like this (with different coded strings)
Altering Your DNS records to Validate
I end up delegating from my main DNS provider to Amazon Route53 for my blog and most static sites. So, while there are records in Amazons Route53 (and you can skip this step if you are totally on the ‘Zon) I’ve been with the same, excellent DNS provider for years (I use DNSimple if you’re interested.).
In your provider of choice, go to their site and navigate down to the DNS records.
Now, this is where you need to be careful. Note the first part of the Name portion that Amazon gave us in the example above.
The key part of that string for validation is
_af6793a4d8984cdae62fac6c9db3b9c6. You need to be very careful when you enter this into the web or cli interface for your DNS provider after the string is evaluated by your provider they have not (as a UX courtesy) added on something like
.awesomesauce.com for you. For example, just pasting this string into the DNSimple interface would have yielded
_af6793a4d8984cdae62fac6c9db3b9c6.awesomsauce.com.awesomesauce.com and validation would have failed. I would not have found out for 72 hours though.
Be extra careful if you have a string where you are specifically doing this for a subdomain in this case. For example, if the above validation had been for
_af6793a4d8984cdae62fac6c9db3b9c6.blog.awesomsauce.com., unless I entered
_af6793a4d8984cdae62fac6c9db3b9c6.blog into the entry fields (yielding
_af6793a4d8984cdae62fac6c9db3b9c6.blog.awesomsauce.com. as the full record.) the validation would also fail and you would not figure it until after an irksomely long time.
The gaff is common enough that Amazon actually has a warning about it on their pages, but it’s better to be aware of it upfront.
So, make sure the Name value is correct for the CNAME and then copy/paste the value in full into the record, with the wildcard example above,
(actually, nice shoutout to Amazon’s UX designers on this: I like the fact you can roll over both the CNAME Name and Value fields and keyboard shortcut copy them to your clipboard. Nice touch.)
I reduced the TTL down to 10 minutes to create the record and waited. And waited. It’s actually annoying you can’t force Amazon to manually check the record with a “Check Now” or something button, but you have to revisit the site. It took around 30+ minutes before Amazon registered that my cert validated. YMMV depending on your provider and DNS propagation at any particular time.
Go make yourself some coffee or a nice cup of tea while you wait for Amazon’s DNS validation. It should say “Success” in green. When you go to check the ACM console screen, you should see an “Issued” in a nice affirmative green after that in the ACM main screen.
Once you see “Issued”, the cert is yours and is usable.
In the ACM console, next to the checkbox for the cert is a little arrow. Click that and you should get a drop down screen that tells you about the Status (issued) and Validation (Success) and then a Heading called
Details will have facts like it being Amazon Issued, a “No” next to “In Use?” and a bunch of additional information that is handy to know. You only care about one item for updating Cloudfront and that is the ARN, the Amazon Resource Name. It’s be a long string like the following:
arn:aws:acm:ca-central-1:331350486233:certificate/89fe6442-d5b4-3844-8780-392c545a36db. You want to copy this string. This will tell Cloudfront this is the security cert it needs to start using.
Now go to your Cloudfront console. Make sure you are in the region for updating the Cloudfront distribution you want.
Click on the nice blue link for your distribution for awesomesauce.com which will be something like
E78GKECGFMRG5 (if you have multiple subdomain cloudfront distributions for awesomesauce.com you will need to update each individually.).
Once you do that, you’ll be in the “General” tab of the distribution screen with an “Edit” button below the tab. Click “Edit” now.
Under “SSL Certificate” the “Custom SSL Certificate (example.com):” radio button should be selected and the current expiring key should be listed by domain name and its unique identifier.
Rotating it to the new key is simply a matter of pasting in the ARN you copied above into the field.
Done. Now just go to the bottom and press the “Yes, Edit” button in blue and you should be back at the ACM console and your new ssl cert is deployed and being used.
Voila. You’re rotated your ssl cert.