Where to terminate TLS
TLS has to be decrypted somewhere before your application can read a request. Where you put that point — at the edge, at a proxy, or all the way at the app — shapes your performance, your certificates and your security.
Every HTTPS request is encrypted until something decrypts it. That termination point is a design decision, not an afterthought: it decides where your certificates live, what sees plaintext, and how much work each layer does.
At the reverse proxy — the common choice
Terminate TLS at a reverse proxy and your applications behind it speak plain HTTP. One place holds the certificates, one place to harden, and the apps are simpler. For most setups this is the right default — the traffic behind the proxy is on your own trusted network.
At the application — end to end
If the path between proxy and app crosses anything you do not fully trust, or compliance demands encryption all the way, terminate at the application — or re-encrypt between proxy and backend. You pay for it in certificate sprawl and CPU, and you buy encryption with no plaintext hop anywhere.
Re-encrypting in the middle
A middle path: terminate at the edge to inspect and route, then open a fresh TLS connection to the backend. You get the proxy’s features and an encrypted internal hop. It costs double the TLS work, which on modern CPUs is usually acceptable.
Certificates follow the decision
Terminating at one proxy means one certificate to renew; terminating at every app means many. Automate renewal wherever the certificates live — see TLS certificates — because the number of them is exactly the number of things that can expire at the worst moment.
Keep the settings strong at the edge
Wherever termination happens, that is where protocol versions and ciphers are decided. Keep it current — see hardening TLS. The termination point is your TLS posture; everything behind it inherits that choice.
Pass the client details inward
Once TLS is terminated, the backend no longer knows it was HTTPS or who the client was unless you tell it. Forward the protocol and client address — the same discipline as in a reverse proxy in front.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base