You are here
General question for anybody who knows how the TKL Let's Encrypt cert request / renewal works. Sure I could read the docs but I would kind of play with this idea and get feedback.
I have a goal of developing "glue code" such that a TKL appliance can be hosted behind a NAT, and set up a reverse proxy to another system with a public-facing IP. In plain English, so that people can host TKL boxes at home (for example) and proxy all traffic thru a $3/mo VPS with a public IP (for example).
I was thinking about how Let's Encrypt certs would have to be handled, as I believe the system TKL uses requires ports (80 and 443?) to be open, and temporarily twiddles webserver configs as needed to request / renew the certs.
My question is, does the Let's Encrypt request/renewal take place entirely over HTTP/HTTPS (such that it could for example be proxied by nginx)? The reason I ask is, merely directly forwarding port 80 and 443 from the VPS to the proxied TKL box for a short time isn't really a good solution, it would be much better to require the proxied TKL box to have a public-facing subdomain, so that (assuming the Let's Encrypt traffic is all normal HTTP[S]) I can tell nginx or similar on the VPS to only proxy the relevant traffic to the proxied TKL box, rather than taking over port 80/443 entirely. This way, it's at least theoretically possible for more than 1 proxied TKL box to be served by a single VPS with public IP.
Does this make sense? Am I completely off base about how Let's Encrypt works on Turnkey Linux? Anybody else have thoughts? I'm currently at the dreaming phase of this project, and experimenting with a lot of the software I'll need to accomplish it, so I'm happy to have input as the building hasn't started yet.
A myriad of options...
There are a myriad of different ways you could achieve your ends.
Although I would argue that the best/easiest for your scenario for getting a Let's Encrypt cert for multiple servers is one Turnkey doesn't currently handle. And that's generating wild card cert(s) via DNS-01 authorisation/authentication. Instead of requiring you to serve a token (as the current TKL implementation does) DNS authorisation is done by providing the authentication token via a TXT record in your DNS config.
Whilst TurnKey doesn't (yet) explicitly.specifically handle DNS-01 authorisation/authentication, Dehydrated (the ACME client TurnKey uses) does support it. I hope to have it supported via HubDNS at some point, but depending on who you have your domain registered with, there may already be a hook script that you can use? You may need to tweak things a bit to get it working with the default TurnKey setup (and it makes much of it redundant) but it certainly should be possible.
If you want to stick within the bounds of how we currently do things, then your idea of proxying the challenges would be doable. Although if you're using a reverse proxy (and don't connect directly to the self hosted TurnKey servers), then probably the easiest way to go is to have the reverse proxy do both the cert termination and manage updating the Let's Encrypt certs. You can then use self signed certs to protect the traffic between the reverse proxy and your local machines (you'll need to either turn off SSL checking; or better still make your self signed cert trusted on your reverse proxy).
FWIW our current Let's Encrypt integration uses HTTP-01 authorisation/authentication. It bundles a super simple webserver (for serving the challenge token via http on port 80) with a wrapper script (which manages starting/stopping services) and a hook script (which copies out the certs to the relevant locations). It's a pretty simple system really. The only limitations are that the DNS A (or CNAME) record of the domain being registered must point to the IP of your server and that the server must serve the relevant token on port 80. We provide a super simple standalone webserver so that we can maintain consistency regardless of which webserver is being used (or none at all even). It also lowers the maintenance overhead.
Happy to answer any other specific questions you might have.
Add new comment