Let's Encrypt has been around since 2016 but I didn't get around to finding it till I built my first GitHub Pages site. I was impressed that although there were warnings that the process could take up to 24 hours the certificate for the custom domain name I specified was created within minutes and I was able to Enforce HTTPS. All this was done on the settings page of a repo that had already been published by entering the custom domain name in the textbox and after the certificate had been generated selecting the checkbox.
By the time I created my blog site I wanted to investigate the Let's Encrypt automated process more. When I saw that I could create a wildcard certificate without giving hundreds of dollars to some company it was a task.
The Let's Encrypt claims its goal is to make encrypted connections to World Wide Web servers ubiquitous. By eliminating payment, web server configuration, validation email management and certificate renewal tasks, it is meant to significantly lower the complexity of setting up and maintaining TLS encryption.
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost. Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal. All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
In 2002 VeriSign, while on the verge of raising the price of some certs by up to 60%, claimed that certificates should not be issued using that type of domain validation. At that time it was GeoTrust selling certs for $119 a year, compared to VeriSign's between $250 and $350 pricing. I believe this was for single domain serts with wildcard certs costing hundreds more. See: There's certs and certs
It was in the early part of this century that I moved the database driven parts of my site to the HTTPS protocol for security. I remember being at a DoD Information Assurance Awareness course on Fort Wainwright being presented by the Army Signal Corps and being shown how much they could see from me interacting with my home server from their lab over http. That had been the initiative to making the move to HTTPS a task. I accomplished the task but used self signed certificates because of the cost. Within the last few months I had already had to address a couple of issues with my self signed certificates. First I created the Unable to view self-signed certificate in Firefox 71.0 (64-bit) Bug report. Later I had to create a new certificate when Apache was complaining about the key being too short. The old key was 1024 bits and the new one was 4096 bits. This was though a manual process I had documented on my private wiki.
With certbot, I spent the most time determining which challenge method and even attempted apache before finding that I wanted to use the oldest DNS-01 which involves creating a TXT record with a hash for each domain name in the certificate. My DNS Provider Hover supports TXT records and provides a simple page to add one to the domains I manage. The page is one I was already familiar with that has fields dependent on the record type selected from a drop-down list including A/AAAA CNAME MX TXT and SRV records. This is from the Add DNS record option I use all the time.
On Ubuntu and Linux Mint the certbot package is included in the official repositories so installation was simple:
sudo apt-get install certbot
I was able to generate and install a LetsEncrypt certificate for the lam1.us and *.lam1.us domains and install it on multiple machines. To use the new keys I modified the /etc/apache2/sites-available/default-ssl.conf file:
SSLCertificateFile /etc/letsencrypt/live/lam1.us/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/lam1.us/privkey.pem
I actually generated a certificate good for *.lam1.us and forgot lam1.us. I had to agree that the IP address will be recorded related to the generation of the certificate, The DNS challenge has me add TXT records to the domain for validation. When I issued the command to generate the certificate with both I was prompted to Extend the existing certificate. I used:
sudo certbot certonly --manual \ --preferred-challenges dns-01 -d *.lam1.us -d lam1.us
The certificates and Expiry dates can be seen with:
sudo certbot certificates
After a little more research I was able to get a certificate for the duckdns.org subdomains I use for Dynamic DNS on my LAM AWS EC2 instances. To use the http-01 protocol I had to stop the apache2 server so that certbot could listen on port 80.
sudo systemctl stop apache2 sudo certbot certonly --standalone --preferred-challenges http-01 \ -d lamurakami.duckdns.org -d lam1.duckdns.org -d lam2.duckdns.org \ -d larryforalaska.duckdns.org sudo systemctl start apache2
Let’s Encrypt CA issues short-lived certificates (90 days). You can attempt to renew any previously-obtained certificates that expire in less than 30 days with:
sudo certbot renew
The Ubuntu package when installed on aws.lam1.us installed a systemd timer that checks twice a day if the certificates need to be renewed. The --deploy-hook is not used and apache2 won't use the new certificate until it is restarted or configuration reloaded. You can see the timer status with:
systemctl list-timers certbot.timer
The complete process of generating and installing Let's Encrypt keys on my server was at least as easy as my regenerate certificate process for a self signed certificate and I get a certificate that browsers accept without pause. The renew process is even easier being automated.
I do have some additional tasks. I wanted a wildcard certificate so the same one could be used on every LAM AWS EC2 instance I launch as well as my machines at home which all get names in the lam1.us domain. I believe Let’s Encrypt has achieved it's goal of significantly lowering the complexity of setting up and maintaining TLS encryption.
Updated with systemd timer info instead of cron job info on Tuesday, June 30, 2020.