Some months ago I had created some certs on my Pi via Let’s Encrypt. I forgot to blog about it and today when I wanted to generate some more certs my mind drew a blank. :) I know I had done something in the past as I could see the certs, but I have absolutely no memory of doing it. That’s the problem when you don’t make a blog entry coz then you have nothing to go back and refer to.
In fact, searching my blog for this today I realized that I had generated some Let’s Encrypt certs for work couple of years ago via PowerShell. When I read the blog post I remembered what I had done, but I had completely forgotten about it.
Anyhoo. Let’s Encrypt. Uses the ACME Protocol. There are many clients that can talk this protocol (I alluded it earlier in the case of OpenBSD which comes with a client of its own). The official client is called certbot. If you go to the certbot website to download it it recommends installing Snap and going that route (yes, even for something like Debian Buster which does not have Snap in-built). Why?! I remember finding an alternative last time around and I came across it again today. Hidden in the docs is a section on how to get it via non-Snap methods, and they have a Debian package too for Buster and above (else install Backports to get it).
|
1 2 |
sudo apt update sudo apt install certbot |
Cool, so that’s that. Next step is to decide how you want to get certs. Back when I did it on OpenBSD it was for a public website so things were slightly easy in that their ACME client could automate things as it knows OpenBSD’s web-server, and it is a publicly available name, so things were smoother.
At home though what I want is to generate certs for each of my machines. The certbot client has plugins for Apache and Nginx but I can’t use them coz my home machines don’t have any public IP. I suppose I could just generate the certs on one machine and copy them around etc. but I want to keep things simple and automatic. In my case the solution would be to use one of their DNS plugins. They support the following:
- certbot-dns-cloudflare
- certbot-dns-cloudxns
- certbot-dns-digitalocean
- certbot-dns-dnsimple
- certbot-dns-dnsmadeeasy
- certbot-dns-gehirn
- certbot-dns-google
- certbot-dns-linode
- certbot-dns-luadns
- certbot-dns-nsone
- certbot-dns-ovh
- certbot-dns-rfc2136
- certbot-dns-route53
- certbot-dns-sakuracloud
Hmm. Step 1, my home DNS zone is a fake one like rakhesh.home so time to get a public one. Step 2, choose one of the providers above I can programmatically access to create DNS records for the ACME verification.
I’ll go with the name raxnet.uk and host it on Route 53. Here’s the documentation for the route53 plugin. The plugin needs to be installed separately; I searched for it in apt and found it as python3-certbot-dns-route53. Instructions to use it are simple and found on their GitHub site and docs.
|
1 |
sudo apt install python3-certbot-dns-route53 |
I created the zone on Route 53 and noted its Zone ID. Next I created a policy in IAM based on the sample offered in the plugin docs (when in the policy screen select JSON and put this in):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
{ "Version": "2012-10-17", "Id": "raxnet.uk-dns-route53 policy", "Statement": [ { "Effect": "Allow", "Action": [ "route53:ListHostedZones", "route53:GetChange" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets" ], "Resource": [ "arn:aws:route53:::hostedzone/Z00811912W0CAEB6R0R0M" ] } ] } |
The policy allows whoever it is applied to to list my zones and also change resource records specifically for the new zone I created (that’s where the Z00811912W0CAEB6R0R0M Zone ID comes in).
I then created a user in IAM. Let’s call it pi1-certbot as I’ll be using this on that particular device and I’d like to have a separate account per device. Tick the option for programmatic access, and leave the console access unticked. I attached the policy I created above to this user and in the final step was given my access keys. You can place these keys in a folder in ~/.aws/config, but I went with making a new file called /etc/pi1-certbot-awskey:
|
1 2 3 |
[default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY |
I also changed this file to be not read/ writeable by anyone else except root.
Next step is to do the certificate request via certbot. I made a script for this so I can reuse:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#!/usr/bin/env bash if [[ -r $1 ]]; then AWS_CONFIG_FILE=$1 \ certbot certonly \ -n --agree-tos --email me@rakhesh.com \ --dns-route53 \ --dns-route53-propagation-seconds 30 \ -d $2 fi # what the options mean: # -n - non-interactive # --agree-tos - agree to the TOS # --email - email address for any urgent messages # --dns-route53 - use route53 as verification option # -d - the domain to verify |
I placed this in /opt. Feel free to place this wherever. This script takes two arguments – one is the credentials file I created above, other is the domain name to create a cert for.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
$ sudo /opt/certbot-renew.sh /etc/pi1-certbot-awskey pi1.raxnet.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Credentials found in config file: /etc/pi1-certbot-awskey Plugins selected: Authenticator dns-route53, Installer None Obtaining a new certificate Performing the following challenges: dns-01 challenge for pi1.raxnet.uk Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/pi1.raxnet.uk/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/pi1.raxnet.uk/privkey.pem Your cert will expire on 2021-03-10. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le |
I’d want this to be renewed automatically so I added this to my root’s crontab via sudo crontab -e:
|
1 |
@daily /opt/certbot-renew.sh /etc/pi1-certbot-awskey pi1.raxnet.uk |
And that’s it. Now I have certs for this host.
Update: I added a -q switch to the command line in my script so there’s no output. Useful since I am adding it as a crontab entry. I am not showing the modification above just wanted to mention for completeness.
Update 2: I made a variant of the above that also copies the certs over. Remember I said I had done this work some months ago? That was for adding certs to some websites hosted internally using Caddy. I couldn’t use Caddy to get certs as the servers weren’t public so I used Let’s Encrypt with Route53 verification. The following variant copies over any updated files to the Caddy certs folder and also restart Caddy so it picks up the new certs.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
#!/usr/bin/env bash if [[ -r $1 ]]; then AWS_CONFIG_FILE=$1 \ certbot certonly \ -n -q --agree-tos --email me@rakhesh.com \ --dns-route53 \ --dns-route53-propagation-seconds 30 \ -d $2 fi if [[ -d /etc/caddy/certs/${2} ]]; then # compare if the fullcert chain has changed if (! cmp -s /etc/caddy/certs/${2}/fullchain.pem /etc/letsencrypt/live/${2}/fullchain.pem); then # if there are changes, copy the file over cp -f /etc/letsencrypt/live/${2}/fullchain.pem /etc/caddy/certs/${2}/fullchain.pem # set ownership to the caddy user chown caddy:root /etc/caddy/certs/${2}/fullchain.pem chmod 644 /etc/caddy/certs/${2}/fullchain.pem # reload caddy systemctl reload caddy fi # compare the private key for the cert if (! cmp -s /etc/caddy/certs/${2}/privkey.pem /etc/letsencrypt/live/${2}/privkey.pem); then # if there are changes, copy the file over cp -f /etc/letsencrypt/live/${2}/privkey.pem /etc/caddy/certs/${2}/privkey.pem # set ownership to the caddy user chown caddy:root /etc/caddy/certs/${2}/privkey.pem chmod 644 /etc/caddy/certs/${2}/privkey.pem # reload caddy systemctl reload caddy fi else mkdir /etc/caddy/certs/${2} chown caddy:root /etc/caddy/certs/${2} cp -f /etc/letsencrypt/live/${2}/fullchain.pem /etc/caddy/certs/${2}/fullchain.pem chown caddy:root /etc/caddy/certs/${2}/fullchain.pem chmod 644 /etc/caddy/certs/${2}/fullchain.pem cp -f /etc/letsencrypt/live/${2}/privkey.pem /etc/caddy/certs/${2}/privkey.pem chown caddy:root /etc/caddy/certs/${2}/privkey.pem chmod 644 /etc/caddy/certs/${2}/privkey.pem fi # what the options mean: # -n - non-interactive # -q - quiet # --agree-tos - agree to the TOS # --email - email address for any urgent messages # --dns-route53 - use route53 as verification option # -d - the domain to verify # list of all the files https://certbot.eff.org/docs/using.html#where-are-my-certificates |