Fully automated dockerized Let's Encrypt reverse proxy | Hacker News Reader

Fully automated dockerized Let's Encrypt reverse proxy

advancedweb.hu

69 pointskiyanwang15 comments

For those not running apache, or afraid of messing with their front end settings. I found the DNS verification system for Let's Encrypt to be a breeze, especially when your DNS provider has an API of some sort (CloudFlare, Route53, etc.)

Do you have any links or tips for getting DNS verification working? Is it simply setting a token on the domain's DNS, then having LE issue a cert with all requested subdomains?

I use the lego[1] client for DNS verification and it works pretty well so far (more deets[2]).

[1]: https://github.com/xenolf/lego

[2]: https://disjoint.ca/til/2016/03/26/lets-encrypt-tls-certific...

Under the hood, yes. You set a TXT record with the challenge token and the certs are issued when LE's servers are able to verify it (a few minutes at most for it to propagate, generally).

However, people already made hooks that take care of that for you for some providers, for example, the CloudFlare one I experimented with:

https://github.com/kappataumu/letsencrypt-cloudflare-hook

Using a reverse proxy with LE is pretty nice as you can have the proxy centralize everything for both local and downstream hosts (I presently do this with the OpenBSD tools). You get a single cert with all the domains used over the entire system. You use the reverse proxy to redirect the challenge location to the local system. LE thinks it is challenging a bunch of different systems but it is just going to the same place over and over again.

Some things don't work all that well behind a TLS proxy. For those systems you need to generate a new outgoing TLS session. You don't need to check the validity of the certificate in most cases and can just use something self signed. I use a never renewed LE cert for convenience.

I seem to remember that Wordpress used a similar approach - a single cert for multiple hosts, any downsides to that?

You would have to trust the proxy to not redirect to the wrong host as you would not get a certificate warning in that case. The proxy can redirect to any host, anywhere, so that doesn't seem to be an issue that could cause extra worry.

In general, all the trust for all the domains would have to rest in the proxy.

Is there an Nginx version already? If not, I'm interested in building one.

This is a great idea!

I use 2 containers to accomplish this:

https://github.com/jwilder/nginx-proxy

https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...

Since both are long running processes, it makes sense to keep them in separate containers.

I just got exactly the same setup working this past week, after deciding to move from ad-hoc setup to a clean Dockerized setup with minimal custom config. It's great!

The thing I like about this setup is that it seamlessly supports multiple vhosts, including SNI for the SSL. I can just create a new container that serves a new domain and set a few environment variables (VIRTUAL_HOST=mydomain.com and LETSENCRYPT_HOST=mydomain.com) and within a few seconds there's a new cert and all requests on that domain are proxied appropriately.

My setup script is here [1] for anyone who wants to do the same.

[1] https://github.com/cfallin/dot/blob/master/doc/setup-grey.c1...

I had various issues with that combo, and also didn't like the repetition of VIRTUAL_HOST and LETSENCRYPT_HOST, so I combined the docker-gen and letsencrypt portion[1]. Still BYO nginx.

I also wrote a tool for deploying and managing static servers and application servers during development[2][3], but it's not ready for a Show HN yet. But the idea is ...

    b3cmd --project foo static-scaffold
    b3cmd --project foo static-put public/ /

... and you'll have a docker-compose project accessible at "foo--master.example.com" and a static server at "foo--master--static.example.com", all HTTPS ready.

[1]: https://github.com/mikew/docker-gen-letsencrypt

[2]: https://github.com/mikew/b3cmd

[3]: https://github.com/mikew/b3cmd-server

> The container utilises Supervisor to start and manage the different services.

That violates the one container, one process design principle, if that's a concern.

Caddy[1] is an interesting single binary cross-platform web server and reverse proxy with built-in Lets Encrypt support.

[1]: https://caddyserver.com/

I've used haproxy a number of times for reverse proxying service requests and terminating SSL. The SSL setup is quite easy, basically just cat the keys together and put the file in a specific place. I'll definitely take a look at this, but I'm honestly not eager to replace haproxy with apache.

SSL Proxy.... terminating ssl... sort of breaks the idea of ssl

No it does not.

Traffic to an "SSL protected appliction" actually stops to be protected at the edge of the web server. Inside everything is in cleartext. An SSL proxy just breaks this cleartext part between two servers.

Of course you need to control both of them and ensure trust between them.

Reply on news.ycombinator.com