This recipe is part of a series about my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates. We will cover migrating the server for our main website from commercially purchased HTTPS certificates to Let’s Encrypt certificates.
- To save money, every little bit helps.
- To be able to reassign the purchased certificates (which support wildcard for multiple subdomains) to our Ezproxy server. More on this in a future recipe in this series.
- Cause, as in “cause I can.” Put in a less cavalier way, it allowed me to gain experience using Let’s Encrypt on a production server. Its only fair that I eat my own dogfood since I am advocating that libraries adopt Let’s Encrypt.
Let’s Encrypt provides both certificates and a set of tools to make installing and renewing the certificates as painless as possible. Here are the overall steps on a Linux Apache Web server that you have shell access to with root or appropriate sudo privileges.
- Get the client application.
- Use the client application to install certificates.
- Set up automatic renewal of certificates.
It was fast and painless to do this on an Apache server running on a modern Linux distro. This will not be as true for some of the recipes I will be sharing later in the series.
Get the Client Application
Let’s Encrypt developed a client application that they initially called letsencrypt to automate many of the steps involved in issuing certificates and installing them correctly in the Web server. In April this year, they released a new version of the client called certbot which will be maintained by the Electronic Frontier Foundation. You will see instructions out on the Web that use the letsencrypt client, it is pretty much interchangeable with the certbot client.
The cerbot client is available for several types of web servers and common Linux distributions. There are also alternative clients and methods that will allow you to install Let’s Encrypt certificates if the cerbot client does not fit your situation. For a number of distros (Ubuntu, ArchLinux, Gentoo, CentOS RHEL 7), the client is available via the common package manager for that distro and can be installed with one command. Alas, our server is still on CentOS 6, so we have a few extra steps.
- Enable the EPEL (Extra Packages for Enterprise Linux) repository. This will make additional dependencies available to the certbot client.
$ sudo yum install epel-release
- Create a directory for where the certbot client will live, this can be anywhere but should probably be in /usr/local or /opt. I selected /usr/local/ and named the directory letsencrypt.
$ sudo mkdir /usr/local/letsencrypt $ cd /usr/local/letsencrypt
- Download the certbot client and make it executable.
$ sudo wget https://dl.eff.org/certbot-auto $ sudo chmod a+x certbot-auto
The certbot client is actually a script that performs a number of tasks:
- examines your system and installs or updates any software dependencies that it needs (python, tlk, http modules, dev tools, etc.);
- creates a virtual environment to work in;
- connects to the Let’s Encrypt certificate authority to request certificates;
- installs the certificates on the server and configures the Web service to use them.
Each time you run the client, it will auto-update itself as well as any software it depends on, so if you run any file integrity or intrusion detection software it will trip alarms. Here is the log of what the certbot client installed the first time it ran on our server. The client provides a lot of options and plugins.
- Run the certbot client to install certificates for two domain names for an Apache server.
$ cd /usr/local/letsencrypt $ sudo ./certbot-auto --apache -d consortiumlibrary.org -d www.consortiumlibrary.org
- Answer the questions the client will ask and wait for it to finish.
email address? I put in my email address. location of ssl configuration files? This defaulted correctly to /etc/httpd/conf.d/ssl.conf. easy (http or https) or secure (only https)? I selected easy.
That’s it, our Web server is now using free HTTPS certificates issued by Let’s Encrypt. It placed the new certificates in /etc/letsencrypt/live and made changes to the ssl.conf to point from our old certificates to our new ones.
We can now tell our commercial certificate authority to revoke our old certificates or to reassign them to another domain.
Let’s Encrypt will only issue certificates for 90 days for some good reasons but this comes as quite a shock to administrators who are used to 1-3 year renewal periods. The idea is that renewal will be automatic so that you will only need to manually deal with certificates when first issuing them or when making changes to domain names. If this proves to be true, Let’s Encrypt with 90-day automated renewals will be less hassle than manually renewing commercial certificates each year.
- Perform a dry-run to renew certificates without making a real request. You should get a message that the test succeeded.
$ cd /usr/local/letsencrypt $ sudo ./certbot-auto renew --dry-run
- Add a cron or systemd job to run the command automatically. The certificates will only renew if they are going to expire in 30 days or less. Let’s Encrypt recommends running the renewal command twice a day. I’m old school so decided to use crontab.
$ sudo crontab -e
Here is an example entry to run renewal once a day at 4:25am.
25 04 * * * /usr/local/letsencrypt/./certbot-auto renew –quiet
The next recipe part of a series will be on installing Let’s Encrypt certificates on a Windows 2008 IIS Server.