TLS Offloading vs Passthrough vs Bridging: Where Does Decryption Happen?

When a load balancer or reverse proxy sits in front of your backends, the decisive question is: where is TLS decrypted? The answer — offloading, passthrough or bridging — determines where the certificates live, where you can inspect traffic, and where data is unencrypted. Here is the difference, and when to choose each.

Short answer

Offloading (TLS termination) decrypts at the load balancer and sends cleartext to the backend. Passthrough lets encrypted traffic pass untouched, so the backend terminates TLS itself. Bridging (re-encryption) decrypts at the load balancer and re-encrypts towards the backend — so you can both inspect the traffic and keep it encrypted the whole way.

Comparison

	Offloading	Passthrough	Bridging
Where is it decrypted?	At the load balancer	At the backend	Both places
LB → backend	Cleartext	Encrypted	Encrypted (new session)
Certificate on	LB	Backend	LB + backend
L7 inspection/WAF	Yes	No	Yes
End-to-end encrypted	No	Yes	Yes

Offloading (TLS termination)

The load balancer decrypts the traffic and forwards it as HTTP to the backend. Pros: one place to manage certificates, the option of L7 routing and a WAF, and backends are freed from the crypto work. Con: the traffic between LB and backend is unencrypted — only acceptable on a trusted, isolated network. This is the classic setup behind a reverse proxy such as nginx or HAProxy.

Passthrough (TCP/SNI-based)

The load balancer does not touch TLS — it forwards the encrypted TCP stream, typically routed by SNI. The backend owns the certificate and terminates itself. Pros: genuine end-to-end encryption and no private key on the load balancer. Con: no L7 inspection, no WAF, and certificate management spreads out across all backends. Used when the requirement is that the LB never sees cleartext — e.g. with mTLS where the backend must validate the client certificate itself.

Bridging (re-encryption)

The load balancer terminates TLS from the client, inspects/routes the traffic, and opens a new TLS connection towards the backend. This gives both L7 features (WAF, routing, caching) and encryption all the way. The price is double the crypto work and certificates in both places: a public certificate on the LB and an (often internal) certificate on the backend. It is the standard choice when compliance requires encryption all the way but you still want to inspect the traffic.

Consequences for certificate management

Offloading: one public certificate on the LB — simple to rotate, but remember the backend leg is unencrypted.
Passthrough: the certificates live on all backends — more places to rotate and monitor.
Bridging: two layers of certificates. The internal backend certificate is often overlooked because it is "not public" — but if it expires, the end-to-end connection breaks.

See how it plays out concretely on F5 BIG-IP (Client SSL / Server SSL profiles) and on Azure Application Gateway and Front Door.

Confirm what is actually served on each leg

Whatever the model, you should verify the certificate both on the front and — with bridging — on the backend leg. Test each leg separately:

# The front: what does the client see?
openssl s_client -connect example.com:443 -servername example.com

# The backend leg with bridging/passthrough (internal name/IP)
openssl s_client -connect 10.0.0.20:443 -servername backend.internal

The blind spot: internal backend certificates

With bridging and passthrough, certificates live on backends and internal services where they never appear in public Certificate Transparency logs and are easily forgotten. CertControl scans both your public endpoints and — via its collector agent — the internal ones, so neither an expired LB certificate nor a forgotten backend certificate becomes a blind spot. See also the ACME pillar on keeping them all renewed automatically.

Frequently asked questions

What is the difference between TLS offloading and termination?

They are the same thing: the load balancer ends (terminates) the encrypted connection and sends cleartext on to the backend. 'Offloading' emphasises that the crypto work is moved away from the backend.

What is bridging or re-encryption?

The load balancer decrypts the traffic from the client, can inspect it, and re-encrypts it in a new TLS connection towards the backend. You get both L7 inspection and encryption all the way.

When should I choose passthrough?

When the load balancer must never see cleartext — typically under strict compliance requirements or mTLS, where the backend itself must validate the client certificate. The trade-off is that you cannot run a WAF or L7 routing on the LB.

Which certificate goes where with bridging?

A public, trusted certificate on the load balancer (what the client sees) and a certificate on the backend (what the LB connects to). The backend certificate is often from an internal CA and is easily overlooked in monitoring.

Is offloading insecure?

Not in itself, but the leg between load balancer and backend is unencrypted. That is only acceptable on a trusted, isolated network. If you need encryption all the way, use bridging or passthrough.

See the platform Book a demo

TLS offloading vs passthrough vs bridging