4 ms·

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

• ceejayoz 10y ago
  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.
  • Namidairo 10y ago
    This along with IPv6 are probably one of the two most visible issues right now.
    • scrollaway 10y ago
      IPv6 support has recently been completed in Boulder (the LE CA software) already: https://github.com/letsencrypt/boulder/issues/593 https://github.com/letsencrypt/boulder/issues/593 That was the main blocking issue. IPv6 in LE is coming very soon.
  • nbevans 10y ago
    Same. The current approach of placing a file on a HTTP endpoint is basically a joke, right?
    • niij 10y ago
      Can you please explain why that is a joke? (I am assuming you are saying the LE verification isn't secure)
  • pfg 10y ago
    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).
    • ceejayoz 10y ago
      > 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.
      • pfg 10y ago
        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).
        • ceejayoz 10y ago
          Now that's an interesting idea I'll have to play with. Thanks!
  • pde3 10y ago
    We're working on it: https://github.com/certbot/certbot/issues/2782 https://github.com/certbot/certbot/issues/2782
• mcguire 10y ago
  "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.
  • pde3 10y ago
    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 https://certbot.eff.org/docs/intro.html#installation
  • pde3 10y ago
    Oh, and it's in use on 500K - 1 million webservers. So extra eyes auditing it are always welcome :)
• majewsky 10y ago
  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.