Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dehydrated: Letsencrypt/acme client implemented as a shell-script

github.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#31

Post by chx »

9dev wrote: post #10
H8crilA wrote: post #3

Earlier quoted context omitted.

Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)

The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…

I am doing docker run -it --rm certbot/certbot

Is there a problem with that?

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#32

Post by groestl »

candiddevmike wrote: post #18
9dev wrote: post #10

Earlier quoted context omitted.

The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…

I'm a simple man, I see a comment complaining about snap and I automatically upvote. It's 2024. If you're still distributing snaps as the preferred method of install, you're alienating your users. AppImage, Flatpak, and regular containers are all far better deployment options.

> If you're still distributing snaps as the preferred method of install, you're alienating your users.

Dropped lxd because of it. Now I hear they're a proper debian package, but that decision was so weird (especially the auto-update part) I don't trust them anymore.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#33

Post by throw0101c »

nullify88 wrote: post #15
lrvick wrote: post #9

Earlier quoted context omitted.

If it is just a few curl and openssl commands, why make a user install hundreds of megs of python deps just to ultimately call mostly openssl commands anyway One of the biggest risks today is supply chain attacks. The more dependencies you have, the more people you are giving the ability to tamper with your critical code paths.

Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?

> Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?

All the packages listed are already probably installed on your system, so you have to worry about their integrity already (your system package manager (RPM, Deb) probably leverages them).

Something like Certbot pulls in dependencies on top of what your system already has, whereas Dehydrated or Acme.sh use tools that you already have to worry about anyway because they're part of the base OS.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#34

Post by groestl »

sirn wrote: post #29
H8crilA wrote: post #3

Earlier quoted context omitted.

Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)

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] Th…

Using it with Hetzner DNS API that way.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#35

Post by sschueller »

teddyh wrote: post #26

Works fine. My only complaint is that it’s a bit slow. Granted, my use case is a bit different than most. $ wc --lines /etc/dehydrated/domains.txt 5161 /etc/dehydrated/domains.txt

At that size I would recommend to dynamiclay generate the domains.txt and only place domains in there that require renewal.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#36

Post by gregmac »

I used this years ago to implement SSL for a bunch of customer vanity domains, and as far as I know it's still operating.

The best thing is it's declarative: you provide a text file with domains you want in each certificate, and it makes it happen.

Certbot has discrete commands you have to run to add, remove, or modify certificates, so you have to keep track of state. We had a management UI to control these domains, so it didn't work well with something like terraform (which I think otherwise solves the state problem for certbot). Instead we just wrote out the domain file based on db config changing + daily, and ran dehydrated. If there were no certificate changes or renewals needed, nothing would happen.

Also the hooks are great, iirc we had a pre-check in place for our own http-01 validation, so as not to cause failures on let's encrypt. (Mostly customers would cname domains to us, but lots could go wrong). We were also using s3 to store the validation files (again, super easy with bash hooks) to make it work across a pool of load balancers.

This is a great example of a tool where a focus on simplicity (config, hooks, and the way it stores everything) creates an incredibly easy to use, flexible (and thus powerful) system.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#38

Post by radiowave »

rany_ wrote: post #7
lrvick wrote: post #4

Earlier quoted context omitted.

Certbot is a massive pile of dependencies that you need to care and feed and update. You should not need 100s of megs of nonsense for something that can be done with a shell script.

It doesn't even work well in my experience. ACME.sh is a lot more hassle free, I've always had issues with Certbot's DNS verification. Basically I'm not avoiding Certbot to make a point, I just think it's inferior for my specific use cases. I don't know about Dehydrated but I also expect it to be BS free.

Yup, I gave up on certbot after trying to understand why I couldn't get the Digital Ocean DNS plugin to work, which is maintained as part of the Certbot repo. (This was a few years ago, so details may have changed.)

I discovered the issue was that the plugin does some pretty broad-brush guesswork about which domain in your DNS hosting it should actually populate with the response value. If you own a bunch of similar domain names (as many orgs do), the plugin may guess wrong.

Much happier to be using dehydrated, and I don't regard it as a major impediment that I had to spend 10 minutes hand writing the necessary API call to the DNS provider.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#39

Post by ExoticPearTree »

vbezhenar wrote: post #28
eigenvalue wrote: post #27

I don’t get why people are saying it’s hard to install Certbot. I just do: sudo apt install certbot python3-certbot-nginx And it “just works” on Ubuntu. The whole thing is super easy and takes around 1 minute to get a cert installed and configured with nginx.

Not everyone's happy to allow certbot to change nginx configs. I never tried it and I'll never try it. Also not everyone wants to install few dozens of packages just for this little thing.

All you need is certbot and a post-hook to restart nginx.

There’s this misconception that you need extra packages to get certificates working with different software.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#40

Post by jraph »

vbezhenar wrote: post #28
eigenvalue wrote: post #27

I don’t get why people are saying it’s hard to install Certbot. I just do: sudo apt install certbot python3-certbot-nginx And it “just works” on Ubuntu. The whole thing is super easy and takes around 1 minute to get a cert installed and configured with nginx.

Not everyone's happy to allow certbot to change nginx configs. I never tried it and I'll never try it. Also not everyone wants to install few dozens of packages just for this little thing.

It has a mode where it doesn't touch your nginx config. That's what I use because indeed, I don't want it to mess with my nginx config.

For the rest, I'll indeed look into lighter alternatives some day. But the setup works on its own so I'm a bit lazy.

Post reply on HN