Configuring Load Balancers for Strict TLS Bridging and Automated Renewals

Load balancers and Ingress controllers serve as the cryptographic front door to modern applications. Because they handle the vast majority of SSL/TLS handshakes, their configuration dictates the security posture of your entire infrastructure.

The stakes for getting this right have never been higher. According to industry data from Keyfactor, 81% of organizations have experienced at least one certificate-related outage in the past 24 months, with severe outages costing upwards of $300,000 per hour. Furthermore, the landscape is actively shifting. With Google and the CA/Browser Forum pushing to reduce maximum public certificate lifespans from 398 days to just 90 days, manual certificate provisioning is no longer a viable operational strategy.

This post breaks down the architectural patterns, cipher configurations, and automation pipelines required to secure edge load balancers in a Zero Trust environment.

The Architectural Shift Away from TLS Offloading

Historically, infrastructure teams relied on a pattern known as TLS Termination, or TLS Offloading. In this model, the load balancer intercepts the HTTPS connection, decrypts the traffic using its installed certificate, and forwards the payload as plaintext HTTP to the backend servers. This approach conserved CPU cycles on backend servers and simplified certificate management by centralizing it at the edge.

Today, TLS Offloading is a severe security liability. It violates the core principles of Zero Trust architecture, which operates on the assumption that internal networks are inherently hostile. Regulatory frameworks, including US Executive Order 14028 and PCI-DSS v4.0, effectively mandate encryption of data in transit across all network segments, both external and internal.

To comply with modern standards, organizations must adopt one of two alternative patterns:

TLS Passthrough

In a TLS Passthrough architecture, the load balancer acts as a pure Layer 4 proxy. It routes the encrypted TCP stream directly to the backend server without ever decrypting it. The backend server holds the TLS certificate and performs the cryptographic handshake.

This pattern is highly secure and is often required for strict HIPAA or PCI compliance environments where the load balancer is explicitly prohibited from accessing the payload. However, because the load balancer cannot see the decrypted HTTP traffic, it cannot perform Layer 7 routing (such as path-based routing like /api vs /web), nor can it inspect traffic using a Web Application Firewall (WAF).

TLS Bridging (Re-encryption)

TLS Bridging is the modern industry standard. In this pattern, the load balancer decrypts the incoming traffic using a public-facing certificate. It then inspects the traffic for malicious payloads, applies Layer 7 routing rules, and re-encrypts the traffic using an internal, private certificate before forwarding it to the backend server.

Here is a practical example of how to configure TLS Bridging in NGINX. Notice that we are not only proxying to an https:// backend, but we are also explicitly verifying the backend server's internal certificate:

server {
    listen 443 ssl;
    server_name api.example.com;

    # Public-facing certificate
    ssl_certificate /etc/ssl/certs/public-fullchain.pem;
    ssl_certificate_key /etc/ssl/private/public-privkey.pem;

    location / {
        # Proxy to the HTTPS backend
        proxy_pass https://backend_servers;

        # Enforce verification of the backend's internal certificate
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 2;
        proxy_ssl_trusted_certificate /etc/ssl/certs/internal-ca-root.pem;

        # Pass necessary headers
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

By enforcing proxy_ssl_verify on, you ensure that the load balancer refuses to connect to a backend server that presents an invalid, expired, or spoofed internal certificate, successfully extending your chain of trust from the edge to the application layer.

Hardening Cryptographic Protocols and Ciphers

Achieving an A+ rating on Qualys SSL Labs requires strict control over which protocols and cipher suites your load balancer is permitted to negotiate.

Protocol Versions

All legacy protocols must be explicitly disabled. SSL v2, SSL v3, TLS 1.0, and TLS 1.1 have been deprecated by the IETF due to fundamental cryptographic flaws. Your load balancer should only negotiate TLS 1.2 and TLS 1.3.

Cipher Suites and Perfect Forward Secrecy

When configuring ciphers, you must prioritize Authenticated Encryption with Associated Data (AEAD) ciphers, specifically AES-GCM and ChaCha20-Poly1305. Older CBC-mode ciphers, RC4, and 3DES are vulnerable to various padding oracle and plaintext recovery attacks.

Furthermore, you must enforce Perfect Forward Secrecy (PFS) by prioritizing Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchanges. PFS ensures that even if your server's private key is compromised in the future, attackers cannot use it to decrypt past captured traffic sessions.

Here is a hardened HAProxy configuration block implementing these standards:

global
    # Restrict to TLS 1.2 and TLS 1.3
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

    # Prioritize strong AEAD ciphers and ECDHE for Forward Secrecy
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

    # Modern TLS 1.3 ciphers
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1

    # Inject HTTP Strict Transport Security (HSTS)
    http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Notice the inclusion of the Strict-Transport-Security header. HSTS instructs the browser that it must only communicate with your domain over HTTPS for the specified duration (in this case, two years). This prevents SSL stripping attacks where a man-in-the-middle attempts to downgrade the connection to plaintext HTTP.

Resolving Certificate Chain and SNI Failures

Even with strong ciphers, improper certificate file preparation is a frequent cause of load balancer errors.

The Incomplete Chain Problem

When a Certificate Authority (CA) issues a certificate, it rarely signs it directly with its Root CA. Instead, it uses an Intermediate CA. If you configure your load balancer with only the leaf certificate, modern desktop browsers might still trust it because they actively cache intermediate certificates from previous browsing sessions. However, API clients, mobile applications, and curl commands will fail with a CERT_UNTRUSTED or unable to get local issuer certificate error.

To solve this, you must bundle the leaf certificate and the intermediate certificate(s) into a single file. The order is critical: the leaf certificate must come first, followed immediately by the intermediate certificate.

# Correct concatenation order for NGINX/HAProxy
cat my_domain.crt intermediate_ca.crt > fullchain.pem

Do not include the Root CA in this bundle. Sending the Root CA over the wire wastes bandwidth during the TLS handshake, as clients already rely on their local trust stores to verify the root.

Server Name Indication (SNI) and Wildcard Sprawl

Historically, organizations purchased wildcard certificates (*.example.com) and deployed them across dozens of distinct load balancers to save money and avoid IPv4 exhaustion. This creates a massive security risk: if a single edge gateway is compromised, the private key for the wildcard is exposed, putting all subdomains at risk.

Modern load balancers rely on Server Name Indication (SNI). SNI allows the client to specify the hostname it is trying to reach during the initial TLS ClientHello. This enables a single load balancer IP address to serve hundreds of distinct certificates. Instead of deploying wildcards, best practice