Let’s Encrypt on Debian/Buster: switching from acmetool to certbot
I have been using acmetool on my Buster server for quite some time. When choosing a client I liked that it is written in Go, that it is small and not overboarding with features, thus I had decided against Certbot and in favor of acmetool. Unfortunately, times are changing and the Let’s Encrypt v1 protocol will be discontinued in June 2020, and in preparation for this I have switched to certbot.
Certbot is somehow the default choice, proposed by Let’s Encrypt and developed by the Electronic Frontier Foundation (EFF). Acmetool is a personal project. Both program versions are quite old in Buster (acmetool 0.0.62-3+b11 and certbot0.31.0-1), while the latest releases are 0.0.67 and 1.1.0 (though I have to say that there are no functional changes in the acmetool releases). Acmetool has a beta version supporting the v2 protocol, but I wasn’t convinced I want to try that out.
So I turned to certbot, and first of all did update the packaging of python3-acme and certbot in Debian to the latest released version 1.1.0. These package can be installed on Debian Buster, testing, and sid:
deb https://www.preining.info/debian/letsencrypt buster main
deb-src https://www.preining.info/debian/letsencrypt buster main
My git updates are available at github: acme-debian and certbot-debian, based on the official (but outdated and broken due to missing pushes in the pristine-tar branch) repositories on Salsa.
The new protocol version of Let’s Encrypt also support wildcard certificates, so I thought I opt for that, but DNS authentication is necessary for that, so I needed a plugin for my DNS registrar, which is Gandi. Fortunately, there is a third-party plugin certbot-plugin-gandi that can do that trick. After installing the package with
pip3 install certbot-plugin-gandi
as root, and saving the API key into /etc/letsencrypt/gandi.ini
, a call to
certbot certonly --certbot-plugin-gandi:dns-credential /etc/letsencrypt/gandi.ini -d preining.info,*.preining.info
gave new certificates in /etc/letsencrypt/live/preining.info
.
What remained is updating the location of keys and certificates in all the domains hosted here, as well as the certificate for the imap server. All in all very painless and quick. Finally, a purge of acmetool
package and removing the according cron job finalized the switch. The certbot package already installs a systemd timer and cron job (which is not run if systemd is used) so updates should be automatized.
Problems
Several things felt a bit painful with the switch to certbot:
- The version in Debian/Buster and sid is too old, and I am not sure whether it would work with the external plugin for gandi. Furthermore, with items like certificates I prefer latest versions incorporating fixes.
- Certbot itself has the problem that one cannot configure external plugins in the configuration file
cli.ini
, see here and here. As seen above, the configuration needs colons in the keys (certbot-plugin-gandi:dns-credential
) but colons are not allowed in keys in the used Python module for config file reading. This is known since 1.5 years (or longer) and unfortunately no progress. - Certbot development seems to be stuck or frozen with respect to external plugin support: About a year ago there was the announcement that the inclusion of plugins will be frozen to clarify the interface etc, but since then no changes.
I can only hope that over time the issues with such an important piece of software will be resolved positively, and I a looking forward to see updates to certbot and friends in Debian.
FWIW, I use dehydrated on tug. A shell script with no significant dependencies. It was straightforward to set up and has worked fine. Hope it lasts a while …
I thought of doing the same, but the fact that the Gandi API has unlimited scope (you can’t, AFAIK, issue a token for just some operations/some records) makes me a bit concerned about giving my token to code that I simply install from pip – not even Debian.
Are you not concerned about this?
I agree with that feeling, but I don’t see a good way out of it. I have looked through the code once, and since it is my buster server, I don’t to pip upgrades unless necessary or I check again. But yes, it is suboptimal.
I thought about using dehydrated (shell script) and write my own Gandi API authenticator, which shouldn’t be too difficult, but then … real life.
acmetool supports the v2 API now.