They're focused on the thing that'll get the most people up and running for the least extra work from them. When you say "push" do you just mean that's the default or are they trying to get you to not use another ACME client like acme.sh or one built in to servers you run anyway or indeed rolling your own?

Like, the default for cars almost everywhere is you buy one made by some car manufacturer like Ford or Toyota or somebody, but usually making your own car is legal, it's just annoyingly difficult and so you don't do that.

As a car mechanic, you could at least tune... until these days when tou can realistically tune only 10..15 years old models, because newer ones are just locked down computers on wheels.

>usually making your own car is legal

It may be legal but good luck ever getting registration for it.

It's actually not that bad in most states, some even have exceptions to emissions requirements for certain classes of self-built cars.

Now, getting required insurance coverage, that can be a different story. Btu even there, many states allow you to post a bond in lieu of an insurance policy meeting state minimums.

Usually making one car, or millions of cars, is doable.

It’s trying to make and sell three or four that is nearly impossible.

Related: Local Motors

https://en.wikipedia.org/wiki/Local_Motors

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.

Plus, it's one of the easier protocols to implement. I implemented it myself, and it didn't take long.

So you're absolutely not dependent on the client software, or indeed anyone else's client software.

There is a plethora of other clients besides certbot or acme.sh.

ISRG (Let's Encrypt's parent entity) wrote Certbot, initially under the name "letsencrypt" but it was quickly renamed to be less confusing, and re-homed to the EFF rather than ISRG itself.

So, what you've said is true today, but historically Certbot's origin is tied to Let's Encrypt, which makes sense because initially ACME isn't a standard protocol, it's designed to become a standard protocol but it is still under development and the only practical server implementations are both developed by ISRG / Let's Encrypt. RFC 8555 took years.

Yes, it started that way, but complaining about the current auto-update behavior of the software (not the ACME protocol), is completely unrelated to Let's Encrypt and is instead an arbitrary design decision by someone at EFF.

As far as I remember, since the beginning certbot/let's encrypt client was a piece of crap especially regarding the autodownload and autoupdate (alias autobreak) behavior.

And I couldn't praise enough acme.sh at the opposite that is simple, dependency less and reliable!

Honestly I abandoned acme.sh as it was largely not simple (it’s a giant ball of shell) and that has led to it not being reliable (e.g. silently changing the way you configure acme dns instance URLs, the vendor building their compatibility around an RCE, etc)