Every HTTPS service behind a load balancer has to answer one architectural question: where does the encryption end? The answer decides which load balancing features you can use, where your CPU cycles go, how you manage certificates, and whether your compliance auditor smiles or frowns.
There are three possible answers. Here is how to choose between them.
Option one: SSL termination
The load balancer decrypts incoming HTTPS and forwards plain HTTP to the backends. TLS ends at the edge.
This is the recommended default for most deployments, because it unlocks everything a Layer 7 load balancer is good at. Once HAProxy can see the requests, you get host- and path-based routing, header inspection and insertion, cookie-based session persistence, and HTTP-aware health checks. Termination also centralises certificate management: certificates live on the load balancer — one place to install, monitor, and renew them — rather than scattered across every backend. With Let’s Encrypt integration, even that one place largely runs itself.
There is a performance dividend too. TLS handshakes are CPU-intensive, and termination moves that work off your application servers onto the appliance. Do note the corollary when sizing hardware: Layer 7 balancing with SSL termination is CPU-hungry at the load balancer, so high-volume HTTPS environments should provision cores accordingly.
The trade-off: traffic between the load balancer and backends travels unencrypted. On a trusted, isolated backend network, many teams accept that. If your security model or your regulator does not, read on.
Option two: SSL passthrough
The load balancer forwards encrypted traffic untouched; TLS terminates at the backend servers. The connection between client and application server is encrypted end to end, and the load balancer never holds a key.
The cost is capability: because the load balancer cannot read the traffic, it is limited to Layer 4 operation. No content-based routing, no header manipulation, no cookie persistence, no HTTP health checks — the balancer sees only IPs and ports. Certificates must be deployed and renewed on every backend individually.
Choose passthrough when compliance genuinely mandates uninterrupted end-to-end encryption, or when backends must present their own certificates for reasons outside your control. It is the right tool for a narrower set of problems than it usually gets used for.
Option three: SSL re-encryption
The hybrid. The load balancer terminates the client-facing TLS session, inspects and routes the traffic at Layer 7, then opens a new TLS connection to the backend. Traffic is encrypted on the wire everywhere — client to balancer, balancer to backend — while the balancer retains full application-layer intelligence in between.
This buys both feature sets at the price of double the cryptographic work: every request is decrypted once and encrypted again. Two mitigations keep the bill manageable. First, the appliance is doing the work, not your application fleet. Second, HAProxy reuses persistent backend connections across client requests, so backend TLS handshakes are amortised rather than paid per request.
Re-encryption is the standard answer where you need L7 features and encrypted backend links — increasingly common under zero-trust network policies and data-protection regimes that treat the internal network as untrusted.
The decision in brief
| Termination | Passthrough | Re-encryption | |
|---|---|---|---|
| L7 routing and persistence | Yes | No | Yes |
| Backend link encrypted | No | Yes | Yes |
| Certificates managed at | Load balancer | Every backend | Both ends |
| CPU cost | One TLS leg | Backend TLS only | Two TLS legs |
| Typical driver | Simplicity, features | Strict end-to-end mandate | Zero-trust + L7 features |
Three questions get you to an answer quickly:
- Do you need content-aware routing, sticky sessions, or HTTP health checks? If no — and you have a mandate for end-to-end encryption — passthrough. If yes, continue.
- Is your backend network trusted enough to carry plaintext? If yes, termination.
- If not — re-encryption.
All three modes are configured when creating a Layer 7 VIP (or, for passthrough, a Layer 4 TCP VIP) under Load Balancing > Virtual IPs.
Whichever you choose: harden the front door
For termination and re-encryption, the load balancer is your TLS front door, and a few settings matter regardless of mode.
Protocol versions and ciphers. Tula ships secure defaults aligned with Mozilla’s TLS recommendations: a Modern profile (TLS 1.3 only) and an Intermediate profile (TLS 1.2 and 1.3) — Intermediate being the sensible choice for most estates. Whatever you pick, TLS 1.0 and 1.1 should stay disabled; TLS 1.2 is the production floor.
HSTS. Have the load balancer add a Strict-Transport-Security header so browsers refuse to downgrade to HTTP. Start with a modest max-age while testing, then raise it to at least a year; enable includeSubDomains only once every subdomain serves HTTPS, and treat the preload flag with caution — leaving the browser preload list is slow and difficult.
OCSP stapling. Enable it so the appliance fetches certificate revocation status from the CA and staples it into handshakes — faster handshakes for clients, and better privacy since clients no longer call the CA themselves.
Keys and chains. RSA 2048-bit is the minimum; ECDSA P-256 offers equivalent security with better handshake performance. And serve the complete certificate chain — server certificate first, then intermediates — because a missing intermediate is the classic "works in Chrome, fails on someone’s phone" mystery. Tula validates uploaded certificates and warns about incomplete chains at upload time.
The deeper reference material is in the SSL termination best practices guide and the certificate management documentation.
The short version
Terminate by default and enjoy the features. Pass through only under a genuine end-to-end mandate, and accept the Layer 4 ceiling knowingly. Re-encrypt when you need the load balancer’s intelligence and an encrypted wire — and let the appliance carry the cryptographic load it was built for.
