You are placing a proxy in front of an HTTPS service and must choose between terminating TLS at the proxy, passing the TLS connection through untouched, and terminating then re-encrypting to the backend. What does each choice buy you, and where does the private key live in each?

## One question decides all three Who completes the client's TLS handshake? Everything else follows from the answer. | | Terminate at edge | Passthrough | Terminate + re-encrypt | |---|---|---|---| | Client's session ends at | proxy | origin | proxy | | Public cert + key live on | proxy | every backend | proxy | | Backend hop | plaintext | the client's own TLS | second TLS session | | Proxy can read HTTP | yes | no | yes | | Backend cert issued by | n/a | a publicly trusted CA | any CA the proxy trusts | ## Terminate at the edge The proxy owns the certificate for the public hostname, decrypts, and forwards plaintext HTTP. This is the default for a reason: it is the only mode in the first two columns where the proxy can behave like an application-aware component. It routes on path and Host, inserts the forwarded headers the backend needs, applies a web application firewall, caches, compresses, retries a failed request against a different backend, and speaks a modern protocol to the client while speaking HTTP/1.1 to a legacy origin. Certificate renewal happens in one tier, which is a genuine operational win once you have more than a handful of backends. What you accept is a plaintext segment and a decryption point. If someone can sniff the internal segment, mirror a port, or read a core dump from the proxy, they read requests — including the `Authorization` header. Whether that matters depends on who else is on that network and what your controls require. ## Passthrough The proxy forwards TCP bytes and never possesses a key for the connection. The client validates the *origin's* certificate directly, which means the origin needs a certificate for the public hostname from a publicly trusted CA, deployed and renewed on every backend instance. Nothing about the request is legible to the proxy: no path routing, no header insertion, no caching, no compression, no HTTP-level retry, no per-request load balancing — the balancing unit is a whole connection, and a long-lived HTTP/2 connection pins one client to one backend for its lifetime. What you get in exchange is narrow but sometimes decisive: the edge is not a decryption point at all. If the edge is a shared platform, a third party, or a tier you would rather not put in scope for an audit, passthrough keeps plaintext and key custody entirely at the origin. It is also the only mode where the *application itself* can verify a client certificate, because a terminating proxy consumes the client's handshake and can only assert what it saw. ## Terminate and re-encrypt The proxy terminates, does all its L7 work on plaintext, then opens its own TLS connection to the backend. Both wire segments are encrypted; the plaintext exists only inside the proxy's memory. This is the usual answer when you need edge routing *and* an encrypted internal hop. The subtlety people miss is the second handshake's trust model. On that hop the proxy is the client, so the backend's certificate does not need to be publicly trusted — an internal CA is normal, and its name only has to match whatever the proxy is configured to expect, which is often an internal service name rather than the public hostname. The corresponding failure is that many deployments quietly disable verification on the backend hop because the internal name did not match. That leaves encryption without authentication: anything that can occupy the backend address terminates the proxy's connection happily, and the proxy never notices. If you re-encrypt, verify — a private CA and a name you actually control make that easy. The costs are real but usually modest: a second handshake (mitigated by keeping backend connections alive and reusing them), CPU for symmetric encryption on both sides, and a second certificate lifecycle to automate. "Two certificates to rotate" is what actually bites, not CPU. ## Choosing Start from what the edge must do. If it has to route on path, rewrite, cache, or shed load intelligently, passthrough is off the table and the question becomes plaintext or re-encrypted inside. If the requirement is that the edge must never see plaintext or hold the key, passthrough is the only mode that delivers it, and you accept connection-level routing. If a control demands encryption on every wire segment while the edge still does L7 work, re-encrypt and verify the backend certificate. A common blended answer is worth naming: terminate at the edge, do the L7 work, and re-encrypt only for the segments that leave a trust boundary — across an availability zone, a datacentre, or into a third party — while an in-rack hop between the proxy and a co-located backend stays plaintext. Mixing modes per route is normal and is usually a better answer than picking one globally.