Hacker News Reader

Comment by pde3 | Hacker News Reader

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!

https://certbot.eff.org

View on HN

"Since it doesn't seem like your operating system has a packaged version of Certbot, you should use our certbot-auto script to get a copy:

    wget https://dl.eff.org/certbot-auto
    chmod a+x certbot-auto

"certbot-auto accepts the same flags as certbot; it installs all of its own dependencies and updates the client code automatically."

I don't know whether to be terrified or horrified.

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.

If you don't like wget; chmod, you can check a gpg signature too: https://certbot.eff.org/docs/intro.html#installation

Oh, and it's in use on 500K - 1 million webservers. So extra eyes auditing it are always welcome :)

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.

This along with IPv6 are probably one of the two most visible issues right now.

IPv6 support has recently been completed in Boulder (the LE CA software) already:

https://github.com/letsencrypt/boulder/issues/593

That was the main blocking issue. IPv6 in LE is coming very soon.

Same. The current approach of placing a file on a HTTP endpoint is basically a joke, right?

Can you please explain why that is a joke? (I am assuming you are saying the LE verification isn't secure)

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).

Now that's an interesting idea I'll have to play with. Thanks!

We're working on it: https://github.com/certbot/certbot/issues/2782

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.

Reply on news.ycombinator.com