I'm currently managing a wildcard certificate that we replace yearly on all our servers, which can be quite a hassle. I've started exploring automated solutions like Let's Encrypt, but there's a catch: my company doesn't allow port 80 to be open, not even on internal networks. For instance, I have an Nginx proxy and an IIS web server. The Nginx proxy uses SSL-bridging, meaning I need the certificate on both the proxy and the web server. What's the best way to simplify this process? I could automate copying the certificate from the proxy to the web server, but then I'd have to manage the certificate store and IIS bindings, which sounds risky if something goes wrong. Am I overcomplicating this? What other solutions are available?
3 Answers
If your servers are internal, consider running your own Certificate Authority (CA). This gives you more control and helps with managing multiple servers, though it does require more setup. Just be mindful of the potential administrative overhead.
There are several tools available for automating Let's Encrypt on Windows, and they can handle IIS bindings too, like Win-ACME. Plus, you don’t even need to open port 80 if you use DNS challenges for verification. It keeps everything neat and compliant without exposing your servers.
We use acme-dns to manage DNS-01 challenges, which works perfectly. Just to clarify, if I'm using a certificate for 'domain.com' on the proxy, can my IIS server have a different independent certificate, or do they both need to match for SSL bridging?
Using IIS as a reverse proxy can simplify your setup. It can handle all your incoming connections and deal with SSL renewals for you through Win-ACME. Your internal web servers can run on HTTP or any HTTPS configuration you choose, and the reverse proxy manages everything, making it a secure single point of SSL management.
But won't that lead to more work for you? It might not be worth the trade-off.