You have installed an SSL certificate on a single web server before. But what happens when one server becomes ten, sitting behind a load balancer that spreads traffic across them? Do you copy the certificate and key onto every machine, and make each one decrypt its own HTTPS traffic? Almost nobody does. Instead they terminate TLS at the edge — one front-facing device handles all the encryption, and the servers behind it focus on the application. This is one of the most common patterns in modern web infrastructure, and it goes by two names that mean the same thing: TLS termination and SSL offloading. This guide explains what it is, the three ways a load balancer can handle TLS, and the security decision that actually matters — what happens to your traffic after it's decrypted.
In short
TLS termination means an encrypted HTTPS connection is decrypted at a load balancer or reverse proxy rather than at the application server. Doing so offloads the costly TLS handshake from your backend pool and lets you manage one certificate in one place. The trade-off: by default the decrypted traffic travels to your backends in plaintext. If that internal hop isn't trusted, you re-encrypt it — a setup called SSL bridging.
What TLS termination is
A TLS connection has two ends: the client (a visitor's browser) and a server that holds the certificate and private key. Termination simply names the server end — the place where the encrypted tunnel stops and the data becomes readable again. In a one-server setup, that end is the web server itself. In a larger deployment, you deliberately move it forward, onto a load balancer or reverse proxy that sits between the internet and your application servers.
Concretely: the load balancer gets the SSL certificate and private key. When a browser connects over HTTPS, the load balancer performs the full TLS handshake, decrypts the request, and then forwards a plain HTTP request to whichever backend server is best placed to answer. The reply travels back through the load balancer, which encrypts it again before sending it to the browser. From the visitor's side, the experience is ordinary HTTPS — a padlock, a valid certificate, no warning. The encryption is real and unbroken between them and your edge. What's changed is purely architectural: the heavy cryptographic lifting now happens in one dedicated spot instead of being spread across every server.
Termination vs offloading: two names, one idea
If you've read a few load-balancer guides you've seen both "TLS termination" and "SSL offloading," sometimes in the same paragraph, and wondered whether they're different features. They aren't. They describe the same operation from two viewpoints:
- Termination describes where it happens — the encrypted connection terminates (ends) at the load balancer.
- Offloading describes the benefit — the TLS work is offloaded from your backend servers onto a device that specializes in it.
You'll also still see "SSL" in both terms even though the protocol in use is TLS — the old name simply stuck, the way people still say "SSL certificate." For the difference between the protocols themselves, our SSL vs TLS vs HTTPS explainer untangles it. For this article, treat termination and offloading as synonyms and focus on the real fork in the road, which is what happens to the traffic after it's decrypted.
How termination works, step by step
Here is the path a single HTTPS request takes through a load balancer that terminates TLS:
- The browser connects to the load balancer. DNS points your domain at the load balancer's address, so the TLS handshake is negotiated with it — not with any backend server. The load balancer presents your SSL certificate.
- The handshake completes at the edge. The load balancer and browser agree on keys and establish the encrypted session. All the asymmetric crypto — the expensive part — is done here, once, by the device built for it.
- The request is decrypted. The load balancer now holds the plain HTTP request and can read it: the URL, headers, and cookies are all visible. This visibility is exactly what lets it route intelligently — by path, by host, by session.
- It forwards to a backend. The load balancer picks a healthy server from the pool and sends it the request. In plain offloading, that hop is clear HTTP; in bridging, the load balancer re-encrypts it first (more on that below).
- The response returns and is re-encrypted. The backend answers, the load balancer encrypts the response with the established session keys, and the browser receives it over the same secure tunnel. The visitor never knows there was a server pool behind the single address they connected to.
Why routing needs decryption: a load balancer can only make Layer-7 decisions — "send /api requests to the API pool, everything else to the web pool" — if it can read the request. Encrypted bytes are opaque. That's the core reason termination is so common: decrypting at the edge is what unlocks smart routing, header rewriting, caching, and web-application firewalls.
Termination, passthrough, and bridging
A load balancer can handle TLS in three ways. They differ only in where decryption happens and whether the internal hop is encrypted — but that difference drives your whole security posture, so it's worth being precise.
| Model | What the load balancer does | Backend hop |
|---|---|---|
| Termination (offloading) | Decrypts the request and forwards it. Sees the full request and can route, cache, and filter on it. | Plaintext HTTP |
| Bridging (re-encryption) | Decrypts, optionally inspects, then opens a new TLS connection and re-encrypts to the backend. | Encrypted HTTPS |
| Passthrough | Does not decrypt at all. Forwards the encrypted bytes; the backend holds the certificate and terminates TLS itself. | Encrypted (end-to-end) |
The quick way to keep them straight: termination decrypts and stops, bridging decrypts and re-encrypts, passthrough never decrypts. Termination gives you the most control and the simplest certificate management but leaves the backend hop in the clear. Passthrough preserves true end-to-end encryption but blinds the load balancer, so it can't do Layer-7 routing or inspection. Bridging is the middle path — full encryption end to end and edge visibility — at the cost of doing the cryptographic work twice.
In zero-trust designs the backend often goes a step further and authenticates the caller as well, so the load balancer or service has to present a client certificate of its own — a setup called mutual TLS (mTLS). That turns the internal hop from "encrypted" into "encrypted and mutually verified."
Why teams offload TLS at the edge
Termination became the default for a handful of practical reasons that compound as your infrastructure grows:
- One certificate to manage, not many. The certificate and private key live on the load balancer alone. Renewals, swaps, and key rotation happen in one place instead of on every server in the pool — which also means fewer copies of your private key to protect. If you're juggling several hostnames behind one balancer, a multi-domain (SAN) certificate or a wildcard certificate keeps that single install covering everything.
- Backends do less work. The TLS handshake — particularly the asymmetric operations — is genuinely CPU-intensive. Concentrating it on a device tuned for the job frees your application servers to spend their cycles on application logic rather than cryptography.
- Layer-7 features become possible. Because the edge can read the request, it can route by URL or hostname, terminate and pool connections, add or rewrite headers, cache responses, and run a web-application firewall. None of that works on opaque encrypted traffic.
- Central policy enforcement. Your TLS version floor, cipher choices, and security headers like HSTS are configured once, at the edge, and apply uniformly — no drift between servers that were set up months apart.
The plaintext-backend risk
Here's the part that's easy to gloss over. With plain termination, the connection from the browser to your edge is fully encrypted — but the hop from the load balancer to your backend servers is clear HTTP. Anything able to observe that internal segment can read the requests and responses in the open, cookies and credentials included.
"Internal" is not the same as "private"
The common assumption is that traffic inside your own network is safe. Sometimes it is — a single isolated subnet with nothing else on it. But "internal" networks are often shared with other tenants in a cloud VPC, span availability zones, or traverse devices you don't fully control. An attacker who gains a foothold inside the perimeter, or a misconfigured peering route, turns that plaintext hop into an easy source of data. Don't treat the internal segment as trusted by default — decide whether it actually is.
This is the same family of mistake as serving a page over HTTPS while it still pulls resources over HTTP — the chain is only as strong as its weakest link. If you've dealt with mixed content errors, the instinct is identical here: a secure front end doesn't help if part of the path behind it is unencrypted.
When to re-encrypt to the backend
The fix for the plaintext hop is bridging — re-encryption. The load balancer still terminates the public connection (so it keeps all its Layer-7 powers), but instead of handing the request to the backend in the clear, it opens a fresh TLS connection to the server and re-encrypts. The data is protected end to end, and the edge can still inspect and route it in the moment between decrypt and re-encrypt.
You don't always need this. A reasonable way to decide:
- Re-encrypt when the data is sensitive or regulated. If you handle payment card data, the PCI DSS standard requires strong cryptography for cardholder data in transit across all networks where it travels — not just the public internet — unless you can demonstrate the internal path is genuinely private. Health, financial, and personal data carry similar expectations. When in doubt for regulated workloads, bridge.
- Re-encrypt when the internal network isn't fully trusted. Shared cloud environments, traffic that crosses zones or data centers, or any segment where other workloads live are all good reasons to keep the backend hop encrypted.
- Plain offloading can be fine when the load balancer and backends sit on a single, isolated, well-controlled segment whose privacy you can actually vouch for, and the data isn't subject to a rule that says otherwise. Many internal services run this way deliberately, for the performance and simplicity.
A note on backend certificates: the certificate the public sees lives on the load balancer, so it must be a publicly-trusted one from a CA. The certificate on the backend hop is only seen by the load balancer, so it can be a privately-issued or internal-CA certificate — many balancers will even accept a long-lived self-signed cert on that leg. Our guide on self-signed certificates covers when that's appropriate and when it isn't.
Configuration gotchas
Termination introduces a few footguns that don't exist when a single server does everything. The usual ones:
- The backend thinks the connection is HTTP. Because the load balancer forwards plain HTTP, your application sees an insecure request and may build redirects or absolute URLs as
http://. The fix is theX-Forwarded-Protoheader: the load balancer sets it tohttps, and your app trusts it to know the original request was secure. Getting this wrong is the classic cause of redirect loops — covered in our guide to redirecting HTTP to HTTPS. - The real client IP disappears. To the backend, every request now appears to come from the load balancer's address. Preserve the original with
X-Forwarded-For(or the PROXY protocol) and configure your app to read it, or your logs and rate limits will all point at one IP. - HSTS belongs at the terminating edge. Since the load balancer owns the HTTPS connection the browser sees, that's where the HSTS header should be set, not buried on a backend whose response headers may get rewritten.
- Set your TLS floor centrally. Configure the load balancer to offer only TLS 1.2 and 1.3 with modern cipher suites. Because every public connection terminates here, this one place defines your whole site's TLS posture.
What this means for you
If you're moving from one server to a load-balanced pool, TLS termination is almost certainly the architecture you want. A few takeaways to carry into the setup:
- Install the public certificate on the load balancer, not the backends. That single install is what the world sees, and managing it in one place is the main operational win. A SAN or wildcard certificate keeps multiple hostnames on that one install.
- Decide consciously about the backend hop. Plain offloading or re-encryption? Answer it on purpose, based on how sensitive the data is and how much you actually trust the internal network — not by accepting the default.
- Forward the protocol and client IP. Set
X-Forwarded-ProtoandX-Forwarded-Forso your application behaves as if it received the original HTTPS request directly. - Centralize your TLS policy. Version floor, ciphers, and HSTS all belong at the terminating edge, where they apply uniformly.
Whichever model you choose, the public-facing certificate is the piece your visitors trust, so it has to be a valid, publicly-issued one. If you're still deciding what certificate that should be — single domain, multi-domain, or wildcard — our step-by-step chooser walks through it. To put termination into practice on a real proxy, our HAProxy SSL installation guide shows the whole setup — building the PEM, terminating at the frontend, and re-encrypting to the backend — while the Nginx and Apache guides show the same certificate at work when you terminate on the server itself.