
Fully automated dockerized Let's Encrypt reverse proxy - kiyanwang
https://advancedweb.hu/2016/05/10/lets-encrypt/
======
phn
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.)

~~~
niij
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?

~~~
marvinpinto
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](https://github.com/xenolf/lego)

[2]: [https://disjoint.ca/til/2016/03/26/lets-encrypt-tls-
certific...](https://disjoint.ca/til/2016/03/26/lets-encrypt-tls-certificates-
using-route53-dns-verification/)

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

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

~~~
upofadown
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.

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

This is a great idea!

~~~
hbz
I use 2 containers to accomplish this:

[https://github.com/jwilder/nginx-proxy](https://github.com/jwilder/nginx-
proxy)

[https://github.com/JrCs/docker-letsencrypt-nginx-proxy-
compa...](https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion)

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

~~~
mikewhy
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](https://github.com/mikew/docker-gen-letsencrypt)

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

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

------
_JamesA_
> 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/](https://caddyserver.com/)

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

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

~~~
BrandoElFollito
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.

