dehydrated

I counted by hand, so it might be wrong, but they appear to list and link to 86 different ACME client implementations across more than a dozen languages: https://letsencrypt.org/docs/client-options/ I've used their stuff since it came out and never used certbot, FWIW. If I were to set something up today, I'd probably use https://github.com/dehydrated-io/dehydrated.

I am pretty sure that this is the thread that introduced me to it: https://news.ycombinator.com/item?id=10681851 Unfortunately, web.archive.org didn't grab an https version of my main site from around that period. My oldest server build script in my current collection does have the following note in it: **Get the current version of dehydrated from https://github.com/dehydrated-io/dehydrated ** (Dehydrated was previously found at https://github.com/lukas2511/dehydrated) ...so I was using it back when it was under the lukas2511 account. Those tech notes however were rescued from a long-dead Phabricator installation, so I no longer have the change history for them, unless I go back and try to resurrect its database, which I think I do still have kicking around in one of my cold storage drives... But yeah, circa 2015 - 2016 should be

Good to see this. For those that weren't aware, there's been a low-effort solution with https://github.com/dehydrated-io/dehydrated, combined with a pretty simple couple of lines in your vhost config: location ^~ /.well-known/acme-challenge/ { alias <path-to-your-acme-challenge-directory>; } Dehydrated has been around for a while and is a great low-overhead option for http-01 renewal automation.

> Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)? And? Automation sometimes breaks, both for internal reasons (OS patching) or external. For the latter, LE at some point in the past changed CDNs, and this caused JWST headers to be sent back differently, which broke different clients, e.g.: * https://community.letsencrypt.org/t/jws-has-no-anti-replay-n... * https://github.com/dehydrated-io/dehydrated/issues/684 Being able to get e-mails was an extra level of monitoring that was handy, even if you had automation.

I feel like acme.sh is the kind of client she's ranting about. 8000 lines of shell code in acme.sh and more in dozens of user-contributed hook scripts, and over 1000 open issues on github? Personally I like https://github.com/dehydrated-io/dehydrated. Same concept as acme.sh but only 2500 lines of shell and 54 open issues. You do have to roll your own hook script though. Curiously, first commits for both acme.sh and dehydrated were in December 2015. Maybe they both took a security class at uni that fall.

> To someone like me with hobby-level serving needs, the 90 day certificate life is pretty inconvenient, despite having automation set up. I've been running an LE client (official one, dehydrated, others) on various system for ~8 years, and the one time I had an issue with renewing was when (AIUI) the LE folks changed CDNs and so their responses were (slightly) different and dehydrated needed to be tweaked: * https://community.letsencrypt.org/t/jws-has-no-anti-replay-n... * https://github.com/dehydrated-io/dehydrated/commit/e4e712c03... Other than that, never had an issue.

What's the motivation behind closing file descriptors 3 and 4? # Close weird external file descriptors exec 3>&- exec 4>&- From this commit: https://github.com/dehydrated-io/dehydrated/commit/b116e6bc2...

Dehydrated and acme.sh seems different. Is one of them fork? https://github.com/acmesh-official/acme.sh https://github.com/dehydrated-io/dehydrated

> And it “just works” on Ubuntu. Sure. Now look at the dependencies that are installed compared to dependencies that are installed for dehydrated (or acme.sh, etc) which generally are: bash, OpenSSL, cURL. This is very handy for more appliance-like system (I ran dehydrated on (RH-based) F5s for years before ACME was put into the GUI; also ran it on (FreeBSD-based) Isilons.) Also, if you want to do an audit of the code, how many lines of Python need to be examined (including dependencies) compared to how many lines of Bash? (Both would have common dependencies like (Open)SSL and HTTP/cURL libraries.) As we saw with the recent XZ kerfuffle, 'software supply chains' are becoming important. Personally I find it much easier to understand / configure dehydrated: $ git clone https://github.com/dehydrated-io/dehydrated.git $ sudo cp dehyd

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just connects to ACME server and calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)[3] This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (~200 LOC) and it worked extremely well. The fact the shell script is so

I've had a lot of success with https://github.com/dehydrated-io/dehydrated . It exposes the different parts of the process (deploy challenge to DNS, deploy cert to filesystem, etc) as hooks, so it's pretty easy to integrate with anything and however you want, if you don't mind writing a bit of bash. There's a few scripts out there that use Cloudflare that you can use as well.

> Oh, and that 500-line shell script probably ends up being a 5000-line Python monster anyway. The dehydrated ACME client is 2400 lines of bash/zsh: * https://github.com/dehydrated-io/dehydrated And its external dependencies are OpenSSL and cURL. The acme.sh shell ACME client is 8000 lines of shell: * https://github.com/acmesh-official/acme.sh The official Let's Encrypt client is written in Python, and the core 'executable' is much longer, and in addition it pulls in a boatload of dependencies: * https://packages.debian.org/bullseye/python3-certbot

Dehydrated.io, damn few dependencies. You're welcome. https://github.com/dehydrated-io/dehydrated

Fan of https://github.com/dehydrated-io/dehydrated