What we'll want in a new Let's Encrypt client

May 12, 2019

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 acmetool 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 'acmetool 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 /var/lib/acme/live/<NAME1>/ 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.)

Comments on this page:

From at 2019-05-12 23:57:26:

I'm always confused by complaints that certbot "touches all your configs". Sure, it does, if you ask it to. But it has always had certbot certonly --webroot (and before the name change, letsencrypt certonly) that does nothing else but obtain a certificate. The actual config-editing plugins need not even be installed.

I've recently switched back to it from acmetool. You can feel the mass of Python code starting up every time, versus acmetool's fast compiled binary, but besides that it works well.

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.

My tool of choice for lightweight ACME clients has been dehyrated. Though you'd be right in designing scripts; it's file driven without a CLI to perform those edits for you. I like that, myself, but I also have the various files it heavily templated out via Ansible already.

I like dehydrated too. I wrote a bit about bootstrapping it on Debian a few weeks ago https://www.dns.cam.ac.uk/news/2019-03-15-lets-encrypt.html

By Albert at 2019-05-13 05:49:32:

In keeping with simple tools, I'm happy with https://github.com/Neilpang/acme.sh. Simple shell script, supports APIv2 and DNS validation (which is what we use), can be run from cron and in a container as well.

From at 2019-05-13 07:07:55:

Third endorsement for dehydrated (and the dehydrated-apache2 Deb package).

Very little magic (which you can inspect since it's just a Bash script), and allows for hooks in various stages. If you want simply, all you have to do is edit the hook.sh file (of which they provide an example) and add a service [webserver] reload line in the deploy_cert() function.

From at 2019-05-14 01:08:50:

since it's just a Bash script

Sorry but that does not inspire any confidence whatsoever in the program.

Written on 12 May 2019.
« Committed address space versus active anonymous pages in Linux: a mystery
Fixing Alpine to work over NFS on Ubuntu 18.04 (and probably other modern Linuxes) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 12 22:30:52 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.