Getting a certificate for HTTPS

I was always put off by the cost of certificates: even one was more than I wanted to spend every year, and getting multiple certificates or a wildcard certificate to deal with the various subdomains was absolutely too much.

The cost issue seems to be moot now. There's a new group called Let's Encrypt, a public benefit corporation, that offers free certificates. They're a collaborative project of the Linux Foundation, and one of their board members is with the Electronic Frontier Foundation, so I was pretty comfortable with using them.

The Let's Encrypt client is now called certbot, and is available via GitHub:

git clone https://github.com/certbot/certbot.git

The executable is certbot-auto. When you run it, the client checks for and installs any libraries needed on your system, so expect some downloading the first time.

The somewhat nonlinear instructions from my web hosting service say that the first step of the process is to create a Certificate Signing Request (CSR) from the shell of my web hosting account. I didn't actually need the CSR anywhere.

The intended use of Let's Encrypt is to run their software on the same machine as your web server, and let it install the certificate itself into your web server. Apparently they have software that will automatically renew the certificate as well. But I use a web hosting service, and as is typical I don't have root access to the web server software. So the option available to me is to create the certificate manually, and send it to my hosting service's system admins.

The client has a GUI, but I prefer the command-line, so the command I needed looked like this:

letsencrypt-auto certonly --text --email MY@EMAIL.ADDRESS --agree-tos --manual-public-ip-logging-ok --renew-by-default --manual -d MY.DOMAIN -d MY.SUB.DOMAIN -d MY.SUB.DOMAIN ...

The domains and subdomains are just the bare names (maraist.org, nst.maraist.org, etc.). There's probably a limit to the number of domains one certificate can hold, but with six I didn't hit it.

What happens next is that the Let's Encrypt client contacts their server and asks it to create the certificate. There's a series of interactions with the user for two reasons:

1. The first one is easy: since Let's Encrypt wants to be transparent about all of their work, every loggable transation needs an explicit approval from the user.

2. The second one is more tedious: they want to verify that you control the domains you're certifying, so you'll need to put small files with a particular single line at specific URLs on your domain.

   This isn't really hard but I ran into one oddity, presumably a Web Faction-specific oddity. Their control panel GUI separates "applications" from "websites" - the former is (for example) a WordPress installation or a directory of static files, while the latter associates several of the former with various URIs. But some kinds of application do not serve the plain files which letsencrypt wants to find in these challenges.

   But the saving grace is that all of these challenge files are in a subdirectory, not the top-level of a URI. That is, the challenge is for a URL like

   http://my.domain/SOME/DIRECTORIES/FILE
   

   and not

   http://my.domain/FILE
   

   It's also helpful that the SOME/DIRECTORIES are weird, obscure names that I'm not otherwise using. So all that means I can create a single application of an application type that will correctly deal with serving plain, suffix-free text files, and associate the one application with the right directories of the several domains. This setup saves the trouble of changing directories for each challenge, which at least for me was an error-prone first try.

The client drops the certificate into a system directory; it will tell you where at the end of its run. I needed sudo to access it; your system configuration may vary. Then I could upload the certificate files to my web hosting service, and some hours later they'd installed it.

Once your certificates are installed, you can verify the installation (in more detail than whether the HTTPS security indicator on your browser turns from red to green) with DigiCert's SSL installation diagnostic.

A downside to Let's Encrypt is that the renewal period for the certificate is three months. There's an email reminder, and the renewal process isn't be too painful - in fact it's exactly the same command as for creating the certificates in the first place. This again produces the four files my hosting service needs, and the renewal is as smooth as the first setup.

An earlier version of this post suggested using the renew command, but that was bad advice. It worked around the brief time of my first renewal, but the renew command is for non-interactive renewal of certificates, for example from a cron job. More recent versions of letsencrypt/certbot will fail when trying to use renew for certificates created with certonly.