Which was a lot more straight forward, so why change it to something obscure? (I mean "Let's Ecrypt" is a well positioned brand and since this is all about trust, why introduce a new name?)
Because it's supposed to be independent of the Let's Encrypt brand, with Let's Encrypt hopefully being one of multiple providers of CAs speaking the ACME protocol and this client being one of many clients compatible with them.
There has been a lot of misunderstanding and FUD about how you can use Let's Encrypt because of the relatively heavy and by default "invasive" official client. This hopefully helps to make it clearer that it is one option of many.
The official client (now Certbot) actually supports a whole bunch of different use cases; some people want full automation of everything; other people find that "invasive". The software supports both, but people would often find the wrong instructions. The new Certbot landing page tries to do a much better job of giving people instructions that are tailored to their use case and needs. Please try it and send us feedback!
certbot-auto (previously known as letsencrypt-auto) is definitely a hack -- it allows people to run the client on typically older OSes that don't have backported native packages. It's basically a tiny autoupdate and packaging system written in bash and python. It uses airgapped signatures for updates, checks sha256 hashes for all of the python dependencies it's installing, and puts them into a python virtual environment so that they don't affect your OS.
Given the emphasis on full automation in Let's Encrypt, it's really baffling that the official client lacks DNS-based support at this time. Anyone behind a load balancer like AWS ELB can't really use it.
HTTP-01 verification works quite well behind load balancers - it's a simple GET request to a specific URL.
You're probably thinking of TLS-SNI-01, which requires changes on the host that's terminating TLS (which isn't possible on a load balancer unless it has dedicated support for ACME).
> HTTP-01 verification works quite well behind load balancers - it's a simple GET request to a specific URL.
Running the client on one of the servers frequently results in it hitting one of the other servers in the cluster. It's a pain in the ass - you either rely on luck and retry a number of times until it hits the right server, or you have to go the more manual route and deploy the challenge directory to all of the servers.
DNS doesn't care how many servers there are, as long as there's the right record in place.
You can work around that fairly easily by having a permanent redirect (HTTP 301) for /.well-known/acme-challenge/* to a dedicated validation server (which might just be certbot in HTTP-01 standalone mode).
Wow, that's really cool. I remember digging through the documentation for days to get everything set up on my systems (nginx on Arch Linux). Now this thing gives me the same information in just two clicks, which is a massive improvement.
An official client implies that other implementations of the standard are unofficial. Building a monoculture around a single client isn't healthy for the project, and nobody wants to put an unofficial client into their security infrastructure.
