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?
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:
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.
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.
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 ...
... 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.
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.
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.
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.
