Hacker News Reader

Comment by davexunit | Hacker News Reader

The official lets-encrypt client has an extremely large dependency graph, and using the client requires server downtime since it takes over port 80. Can either of these things be improved?

View on HN

Yes, this greatly annoyed me too especially given the 3 month expiry time. https://github.com/diafygi/acme-tiny is a tiny alternative client without any dependencies (except python itself), and you can use any web server including your usual running one to serve the challenge responses up.

Awesome. Exactly what I was hoping to hear. Thanks!

It also requires the openssl executable in your path.

Luckily, it's less than 200 lines and open source! Please feel free to fork it and modify for your needs :)

I was just clarifying for other readers. I looked through it because I've been working on some Python crypto stuff for a while, so I was curious what it used since the statement above was that it only required Python.

I think you should double check the taking over port 80 thing. There are a number of authenticators that do not require taking down your existing webserver. I've used the webroot authenticator to get several certificates without taking down anything.

Not supported on all platforms though, on my FreeBSD box the only option it gave me was to take down the web server. Maybe it's possible with manual config?

There is an option to run it in a different port which will allow you to reverse proxy to it.

--standalone-supported-challenges http-01 --http-01-port 9999

Will make it listen on port 9999. Their server will only connect to the official ports of course, so you need to reverse proxy

Nice, I really like that idea. Any information on what paths I'd need to reverse proxy to it?

In NginX you would need the following location (with different contents):

    location /.well-known/acme-challenge/ {
      alias /var/www/challenges/;
      try_files $uri =404;
    }

Snippet from https://github.com/diafygi/acme-tiny documentation.

I can understand some of the need for this. On the other hand you could make it trust all privileged ports, which implies root access - but this is a separate concern for other users.

You installed py27-letsencrypt from ports? I posted a command in here that I used on FreeBSD and it worked find to register a certificate without disturbing the running web server. The webroot authenticator does work in FreeBSD.

I used the git version actually and it complained that it couldn't configure my web server, what's needed to use the webroot authenticator?

It's one of the plugins included with the client. See [1] for more.

[1]: https://letsencrypt.readthedocs.org/en/latest/using.html#web...

Yeah, this gets really tedious though because you have to do special configuration for every vhost you want SSL on, nginx doesn't appear to offer a way to do global location directives.

Maybe I'll just write a firewall rule to redirect traffic from letsencrypt IPs over to the standalone client.

I think you can create an include file with all the SSL configuration like cipher lists, Let's Encrypt support etc and just include it once for every vhost that uses SSL. Probably won't save time initially, but it should make changes like this faster in future.

The client supports being plugged into your running instance of nginx/apache as long as it can provide the appropriate .well-known paths.

Yep. The option is called 'webroot' and using letsencrypt-auto (the offical client) I deployed this on a few servers and setup cron to renew automatically. It's not very well documented (at least wasn't when I last checked).

Reply on news.ycombinator.com