Bit of a followup to my previous post. I now have a VPS with nginx working as a reverse proxy to some services on my DMZ. My router (UDM pro) is running a wireguard server and the VPS is acting as a client.
I’ve used Letsencrypt to get certs for the proxy, but the traffic between the proxy and the backend is plain HTTP still. Do I need to worry about securing that traffic considering its behind a VPN? If I should secure it, is there an easier way to do self-signed certs besides spinning up your own certificate authority? Do self-signed certs work between a proxy and a backend, or would one or the other of them throw a fit like a browser does upon encountering a self-signed cert?
I’d rather not have to manage another set of certs just for one service, and I don’t want to involve my internal domain if possible.
Self signed for this use case is fine. you know and trust both ends of your connection, and no one else needs to know or trust either end of the connection.
This is fine unless you have a slightly higher threat model.
Me personally, I dislike the idea that if someone (VPS provider or LE) were to snoop inside my VPS, they would have all of my unencrypted data where TLS ends and wireguard picks it up.
I don’t do anything illegal, but I do have photos, personal files, and deeply personal journals/notes for which I enjoy the comfort of mind when kept private and secure.
My recommendation is always to have your TLS equipped reverse proxy on your own hardware. Then use a VPS as a SSL passthrough proxy that forwards requests to the locally hosted reverse proxy. You can connect the two via wireguard.
This has a few benefits. It keeps encryption end to end. It also allows you to connect to your server via your domain name even in you LAN. You can hijack your domain at the router level DNS menu to reroute to your local reverse proxy. And it keeps the TLS connection.
Question, how do you deal with the certificates if you have an external vps doing passthroy?
Because that certificate will not match the domain name of the vps and then everything will fail or at least trigger a lot of alerts.
I really fail to see how an internal backend in a different subnet can send the right certificate
There’s no certificate at the VPS level. It forwards everything to and from the self hosted reverse proxy.
Now that you mention it though, there may be a slight complication with pinning the reverse proxy to the domain API for cert renewals. I’ll have to check how I have mine configured but I may have given my reverse proxy a IPv6 and configured that for cert renewals.
That would mean some down time as you update the IP if your ISP rotates it.
You don’t need a cert authority to self-sign. You can do it once and be good to go.
is there an easier way to do self-signed certs besides spinning up your own certificate authority?
Letsencrypt works fine, just use a “real” domain and DNS challenge.
Your service will need to be on the “real” domain, but it won’t need to be accessible externally and you won’t need a public DNS entry for it (of course your VPS will still need to be able to resolve the backend’s name).
Self signed certs are usually created with OpenSSL. Find an example online. If you own a domain create your cert against that name.
The better option is to get your backend also using let’s encrypt and change to https. The whole point of lets encrypt is “encrypt all the things”
You should be able to fix your browser cert error messages by adding the cert to your trusted root store. Easy to do on desktops, mobile devices might be harder to do without an MDM.
What I’ve usually seen is that the VPS does TLS termination and then comms between the VPS and the LAN are sent http, but still secure due to traveling through the VPN. This is the easiest way if you don’t require full e2ee and trust your LAN
