What we'll want in a new Let's Encrypt client
Over on Twitter, I said:
It looks like we're going to need a new Let's Encrypt client to replace acmetool (which we love); acmetool uses the v1 API and seems to no longer be actively developed, and the v1 API runs into problems in November: <link: End of Life Plan for ACMEv1>
(There is an unfinished ACMEv2 branch of acmetool, but, and also. It would be ideal if the community stepped forward to continue acmetool development, but sadly I don't see signs of that happening so far and I can't help with such work myself.)
November is when Let's Encrypt will turn off new account registrations through ACMEv1, which is a problem for us because we don't normally re-use Let's Encrypt accounts (for good reasons, and because it's easier). So in November, we would stop being able to install acmetool on new machines without changing our procedures to deliberately reuse accounts. Since doing so would only prolong things, we should get a new client instead. As it happens, we would like something that is as close to acmetool as possible, because acmetool is basically how we want to handle things.
Rather than try to write a lot of words about why we like
so much (with our custom configuration file),
I think it's simpler to demonstrate it by showing you the typical
install steps for a machine:
apt-get install acmetool mkdir /var/lib/acme/conf cp <master>/responses /var/lib/acme/conf/ acmetool quickstart acmetool want NAME1 ALIAS2 ...
(Alternately, we copy
/var/lib/acme from the live version of the
server. We may do both, using '
want' during testing and then overwriting it with the official
version when we go to production.)
After this sequence, we have a new Let's Encrypt account, a cron job that automatically renews
certificates at some random time of the day when they are 30 days
(or less) from expiry, and a whole set of certificates, intermediate
chains, and keys accessible through
and so on, with appropriate useful permissions (keys are root only
normally, but everything else is generally readable). When a
certificate is renewed,
acmetool will reload or restart any
potentially certificate-using service that is active on the machine.
If we want to add additional certificates for different names,
that's another '
acmetool want NAME2' (and then the existing cron
job automatically renews them). All of this works on machines that
aren't running a web server as well as machines that are running a
properly configured one (and these days the Ubuntu 18.04 acmetool
package sets that up for Apache).
(We consider it a strong feature that acmetool doesn't otherwise attempt to modify the configurations of other programs to improve their ability to automatically do things with Let's Encrypt certificates.)
Acmetool accomplishes this with a certain amount of magic. Not only does it keep track of state (including what names you want certificates for, even if you haven't been able to get them yet), but it also has some post-issuance hook scripts that do that magic reloading. The reloading is blind (if you're running Apache, it gets restarted whether or not it's using TLS or acmetool's certificates), but this hasn't been a problem for us and it sure is convenient.
We can probably duplicate a lot of this by using scripts on top of some other client, such as lego. But I would like us to not need a collection of home-grown scripts (and likely data files) to mimic the simplicity of operation that acmetool provides. Possibly we should explore Certbot, the more or less officially supported client, despite my long-ago previous experiences with it as a heavyweight, complex, and opinionated piece of software that wanted to worm its way into your systems. Certbot seems like it supports all of what we need and can probably be made to cooperate, and it has a very high chance of continuing to be supported in the future.
(A lot of people like minimal Let's Encrypt clients that leave you to do much of the surrounding work yourself. We don't, partly because such additional work adds many more steps to install instructions and opens the door to accidents like getting a certificate but forgetting to add a cron job that renews it.)
(My only experimentation with Certbot were so long ago that it wasn't called 'certbot' yet. I'm sure that a lot has changed since then, and that may well include the project's focus. At the time I remember feeling that the project was very focused on people who were entirely new to TLS certificates and needed a great deal of hand-holding and magic automation, even if that meant Certbot modifying their system in all sorts of nominally helpful ways.)