I’ve used a variety of certificate providers over the years, Thawte, CA-Cert, Verisign, Comodo, Startcom. Until about six months ago I was using Startcom, and had spent a fair amount of energy setting that up for my own site (this one) as well as all the other sites I manage.

Then Wo-Sign acquired Startcom, and browsers starting distrusting Startcom. I ended up buying a cert from Comodo for this site.

But then I found out about Let’s Encrypt. Not only are they free, but they have this whole ACME auto update thing worked out, using various ACME clients. I’ve been using Certbot from EFF.

Downloaded certbot-auto and installed on tarragon. Tarragon is still F22 at this writing and no certbot package.

Basic usage is:
certbot-auto –apache

This provides a numbered list of web addresses. You pick addresses to be covered by a single certificate, e.g. 20,21,23 and it will:

a) get a certificate from Letsencrypt which covers those domains.

b) update the apache config files

He reads the apache config files to do this. For me, Apache includes from active-sites.d, which contains symlinks to defined-sites.d. He follows the symlinks. If the apache config file already has a virtualhost 443, certbot will change the directives which specify the location of the certificate and key. If the apache config file does not contain a virtualhost 443, certbot will create a new config file <sitename>-le-ssl.conf but he will put it in active-sites.d, instead of defined_sites.d as I would do, so I have to move it. In actual fact, what I do is move the virtualhost 443 content into the existing config file.  But it is better to already have the virtualhost 443 in the site definition.

I had a couple of cases where there was both a bare and a www name, and he decided, for some reason, that the certificate acquired and the directory name in his files should be names with the www form of the name instead of the bare form. This is a pain in the butt for me, because of the way I have the certs set up in the repo, so I had to change it. Fixed it with:

certbot delete
certbot-auto –apache [select bare form name]
certbot-auto –expand -d barename.com -d www.barename.com

Within /etc/letsencrypt the ‘archive’ directory holds the certificates that have been obtained, in directories named for the common name of the cert, eg archives/<sitename>.com. There are files there cert<n>.pem, chain<n>.pem, fullchain<n>.pem and privkey<n>.pem. where <n> is incremented on renewal – so a set of 4 files for each renewal. Another directory /etc/letsencrypt/live also contains a directory for each sitename, live/<sitename>.com, and within it are 4 symlinks, named cert.pem, chain.pem, fullchain.pem and privkey.pem which point at the latest <n> in the archive directory.

Also within /etc/letsencrypt is a directory ‘renewal’, within which is a .conf file for each sitename. This file has information to enable renewal, and also has the names of the directory where the certificates sit. E.g. in <sitename>.conf there is a spec

archive_dir = /etc/letsencrypt/archive/<sitename>.com

and there are also similar entries that say cert=, privkey=, chain=, and fullchain= each of which is the absolute location of where certbot should place the symlink to the most recent cert file. E.g. in the standard setup

cert=/etc/letsencrypt/live/<sitename>.com/cert.pem

tells certbot when it updates the certificate for <sitename> the specified location of the symlink that needs to be changed to point to the new stuff.

I altered the archive_dir to say

archive_dir=/etc/pki/mycerts/svncertificates/<sitename>

for all the sites. So that newly renewed certificates will be placed into the svn versioned directory, so I can save the certificates into the repo.

The private keys for these certificates are changed every time the certificate is renewed. But since it is so easy to obtain a new cert with a new key, it no longer seems to be important to keep these backed up. In fact, it may not make any sense to keep these certificates in the repository at all? It does, however, still make sense to have them in the /etc/pki/mycerts directory, because that gets preserved across a system reinstall.

All the new certificates are in the repository, without the private keys. There is an svn:ignore in the svncertificates directory to prevent saving the private keys.

In the tarragon_backup script, there is a:

certbot renew