I have a containerized application that normally runs behind SSL termination in the cloud. Locally, I'd prefer to keep the application speaking plain HTTP rather than install certificates inside the container. Is there a simple way to run SSL offloading locally? I'm fine with browser certificate warnings and don't necessarily want to create or install a trusted certificate authority.
4 Answers
The certificate still has to exist somewhere on the TLS endpoint, so moving TLS termination to another container or process doesn’t eliminate certificates entirely. It just keeps them out of the application container. A proxy image with mounted certificate storage is usually the cleanest compromise, and a local certificate tool can create a trusted certificate if warnings become annoying.
You can also run a reverse proxy in a separate VM or service and use a real certificate through an automated certificate authority. That takes more setup, especially if the service is only reachable locally, but it can automatically renew certificates and avoid browser warnings when you use a suitable hostname.
A small reverse proxy running on the host works too. For example, a Node or Express server can listen for HTTPS, use a self-signed or expired certificate, and forward requests to the container over regular HTTP. You still need a certificate for the HTTPS listener, but it doesn’t have to be trusted if you’re okay accepting the warning in your browser.
Put a reverse proxy in front of the container and terminate TLS there. The application can continue using plain HTTP on an internal container network. Caddy is an easy option because it can generate a local certificate automatically. A minimal configuration would proxy https://localhost to the app’s internal port, with TLS configured as internal. You can leave the local CA untrusted if browser warnings are acceptable. Don’t publish the app port directly unless you need access to it; let only the proxy reach it internally. Caddy, Nginx, Traefik, and HAProxy can all handle this. If the app needs the original protocol or client address, configure it to trust the proxy’s X-Forwarded headers only from the internal proxy network.

That makes sense. I mainly want the application image to stay unchanged, so keeping the certificate and TLS configuration in a separate proxy container sounds like the best fit.