I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu.

My favourite client is probably https://github.com/acmesh-official/acme.sh

If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should help if you're twitchy about running a complex script on it. It's also got the advantage of allowing you to get certificates for internal/non-routable addresses.

▲ JoshTriplett 2 days ago | parent | next [-]

Certbot is definitely one of the strongest arguments against ACME and Let's Encrypt.

Personally, I find that tls-alpn-01 is even nicer than dns-01. You can run a web server (or reverse proxy) that listens to port 443, and nothing else, and have it automatically obtain and renew TLS certificates, with the challenges being sent via TLS ALPN over the same port you're already listening on. Several web servers and reverse proxies have support for it built in, so you just configure your domain name and the email address you want to use for your Let's Encrypt account, and you get working TLS.

▲

Shadowmist 2 days ago | parent [-]

Does this only work if LE can reach port 443 on one of your servers/proxies?

	▲	JoshTriplett 2 days ago \| parent [-]
		Yes. If you want to create certificates for a private server you have to use a different mechanism, such as dns-01.

▲ skywhopper 2 days ago | parent | prev | next [-]

Certbot goes out of its way to be inscrutable about what it’s doing. It munges your web server config (temporarily) to handle http challenges, and for true sysadmins who are used to having to know all the details of what’s going on, that sort of script is a nightmare waiting to happen.

I assume certbot is the client she’s alluding to that misinterprets one of the factors in the protocol as hex vs decimal and somehow things still work, which is incredibly worrisome.

▲ castillar76 2 days ago | parent | next [-]

Having my ACME client munge my webserver configs to obtain a cert was one of the supreme annoyances about using them — it felt severely constraining on how I structured my configs, and even though it’s a blip, I hated the double restart required to fetch a cert (restart with new config, restart with new cert).

Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HTTP snippet in my server set to serve up ACME challenges from a static directory and push everything else to HTTPS, and the ACME client just needs write permission to that directory. I can dynamically include that snippet in all of the sites my server handles and be done.

If I really felt like it, I could even write a wrapper function so the ACME client doesn’t even need restart permissions on the web-server (for me, probably too much to bother with, but for someone like Rachel perhaps worthwhile).

▲ ndsipa_pomu 2 days ago | parent [-]

A wrapper function may be overkill when you can do something like this:

  letsencrypt renew --non-interactive --post-hook "systemctl reload nginx"

	▲	castillar76 21 hours ago \| parent [-]
		Oh definitely, but her point was she didn’t want the ACME client having the rights to frob the webserver — I figured that meant restart-rights too. :)

▲ jeroenhd 2 days ago | parent | prev | next [-]

With the HTTP implementation that's true, but the DNS implementation of certbot's certificate request plugins don't touch your server config. As an added bonus, you can use that to also obtain wildcard certificates for your subdomains so different applications can share the same certificate (so you only need one single ACME client).

▲ claudex 2 days ago | parent | prev | next [-]

You can configure certbot to write in a directory directly and it won't touch your web server config.

▲ ndsipa_pomu 2 days ago | parent | prev [-]

> It munges your web server config (temporarily) to handle http challenges

I run it in "webroot" mode on NgINX servers so it's just a matter of including the relevant config file in your HTTP sections (likely before redirecting to HTTPS) so that "/.well-known/acme-challenge/" works correctly. Then when you do run certbot, it can put the challenge file into the webroot and NgINX will automatically serve it. This allows certbot to do its thing without needing to do anything with NgINX.

▲ christina97 2 days ago | parent | prev | next [-]

I used to like them, then they somehow sold out to zerossl and switched the default there from LE after an update.

Pinned to an old version and looking for a replacement right now.

▲ Bender 2 days ago | parent | next [-]

That annoyed me as well given the wording on the ZeroSSL site suggested one has to create an account which is not true. I had hit an error using DNS-01 at the time. They have an entirely different page for ACME clients but it is not or was not linked from anywhere on the main page.

If anyone else ran into that it's just a matter of adding

    --server letsencrypt

	▲	castillar76 2 days ago \| parent [-]
		You can also permanently change your default to LE — acme.sh actually has instructions for doing so in their wiki. I rather liked using ZeroSSL for a long time (perhaps just out of knee-jerk resistance to the “Just drink the Koolaid^W^W^Wuse Let’s Encrypt! C’mon man, everyone’s doing it!” nature of LE usage), but of late ZeroSSL has gotten so unreliable that I’ve rolled my eyes and started swapping things back to LE.

▲ ndsipa_pomu 2 days ago | parent | prev [-]

I only started using it after the default was ZeroSSL, but it's easy to specify LetsEncrypt instead

▲ notherhack a day ago | parent | prev | next [-]

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.

▲ 12_throw_away 2 days ago | parent | prev | next [-]

Dunno about the protocol, but man, working with certbot and getting it do what I wanted was ... well, a lot more work than I would have guessed. The hooks system was so much trouble that I ended up writing my own.

But yeah, can definitely recommend DNS-01 over HTTP-01, since it doesn't involve implicitly messing with your server settings, and makes it much easier to have a single locked server with all the ACME secrets, and then distribute the certs to the open-to-the-internet web servers.

▲ corford 2 days ago | parent | prev | next [-]

Agree with the acme.sh recommendation. It's my favourite by far (especially, as you point out, when leveraging with DNS-01 challenges so you can sidestep most of the security risks the article author worries about)

▲ egorfine 2 days ago | parent | prev | next [-]

certbot is complexity creep at it's finest. I'd love to hear Rachel's take on it.

+1 for acme.sh, it's beautiful.

▲ xorcist 2 days ago | parent | prev [-]

acme.sh is 8000 lines, still a magnitude better than certbot for something security-critical, but not great.

tiny-acme.py is 200 lines, easy to audit and incorporate parts into your own infrastructure. It works well for the tiny work it does but it does support anything more modern.