User Tools

Site Tools


crypto:letsencrypt

Let's Encrypt Usage Notes

We're currently using Let's Encrypt to generate and manage TLS certificates for quay.net and several other domains.

Now that Let's Encrypt supports wildcard certs, our cert has been modified accordingly. Currently quay.net is hosted on Amazon's EC2 and uses the AWS Route 53 service for public DNS on the Internet. Ideally we'd be using the certbot-dns-route53 plugin, however it is not available in the OS distribution of certbot in Debian 9 and installing and running it from source is a dependency nightmare that isn't worth the effort for such a simple use case.

Thus, we'll use the manual process for generating and managing our certificates. Let's get to it!

certbot manual DNS validation

First we'll install the distribution package for certbot + dependencies:

apt install certbot

Now let's request a new certificate, we're going to have to make some manual changes to DNS and add a challenge response for the ACME service after we do this.

sudo certbot --manual --force-interactive certonly

Enter our domains at the prompt.

quay.net *.quay.net gabriel.to *.gabriel.to gabrielobrien.ca *.gabrielobrien.ca k538.ca *.k538.ca unx.is *.unx.is badphoto.ca *.badphoto.ca badphotography.ca *.badphotography.ca

If all goes well, you will now be prompted to update a DNS TXT record for each domain as well as a file on the local webserver to allow the ACME service to validate that you actually control the domain(s) in question.

On our server we use an nginx configuration file that can be enabled or disabled to turn on shared challenge files during certificate renewal.

# USAGE: enable this configuration for Route 53 validation for Let's Encrypt
location /.well-known/acme-challenge {
       alias /path/to/shared/acme-challenges;
       autoindex off;
}
Note: locally we have to manage some custom config for badphotography.ca.

The instructions are provided at each step and are fairly simple. The prompt will look something like this for the DNS records:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.quay.net with the following value:
 
<a random string of characters>
 
Before continuing, verify the record is deployed.
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

After you have made the DNS changes for each domain, you will be prompted to create the challenge responses on your webserver, again instructions are provided.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:
 
<another random string of characters>
 
And make it available on your web server at this URL:
 
http://quay.net/.well-known/acme-challenge/<yet another string of characters>
 
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet.)
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

If all goes well, then your cert will be updated and you just need to restart your webserver(s). If not, read the error message or the logs and it should give you a hint of what went wrong. The most common issue will be a typo or cut-and-paste error.

It's a good idea to clean up these records now to avoid a potential backdoor that might allow somebody to take over your certificate and/or webserver. You only need to do this every 90 days, and eventually the route53 package will be properly integrated in Debian 9.

crypto/letsencrypt.txt · Last modified: 2019-05-21 22:00 by gabriel