How to Handle SSL Certificates in a Load-Balanced Environment

Vidensdatabase

When traffic is distributed across multiple servers, SSL certificate management needs coordination — ensuring every backend server has a consistent, current certificate, or centralizing TLS termination at the load balancer itself.

Two Main Architectural Approaches

TLS Termination at the Load Balancer — the load balancer handles HTTPS, communicating with backend servers over plain HTTP internally.
TLS Passthrough / End-to-End Encryption — each backend server handles its own TLS, with the load balancer passing encrypted traffic through unmodified.

Approach 1 — TLS Termination at the Load Balancer (Simpler, Common)

upstream backend_servers {
    server 10.0.0.10:80;
    server 10.0.0.11:80;
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://backend_servers;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Only the load balancer needs a certificate — simplifies renewal and management significantly, since there's a single certificate to maintain rather than one per backend server.

Important: Internal Traffic Is Unencrypted

With this approach, traffic between the load balancer and backend servers travels as plain HTTP — acceptable if this traffic stays within a trusted private network, but ensure it's genuinely isolated (private network/VPC, not traversing the public internet unencrypted).

Approach 2 — TLS Passthrough (End-to-End Encryption)

stream {
    upstream backend_ssl {
        server 10.0.0.10:443;
        server 10.0.0.11:443;
    }

    server {
        listen 443;
        proxy_pass backend_ssl;
    }
}

Each backend server needs its own valid certificate for the domain — more complex to manage (certificate renewal must be coordinated across all backends) but maintains encryption for the entire path.

Synchronizing Certificates Across Multiple Backend Servers

If using per-server certificates, options include: a shared/synced certificate directory, a centralized certificate management tool distributing renewed certificates automatically, or a DNS-01 challenge-based renewal process run from one central location that then distributes the resulting certificate.

Using DNS-01 Validation for Coordinated Renewal

See How to Install a Wildcard SSL Certificate with Certbot DNS Challenge — DNS-01 validation doesn't require the challenge to be served from each specific backend server, simplifying renewal coordination in a multi-server setup.

Health Checks and Certificate Validity

Ensure your load balancer's health checks would actually catch a backend server serving an expired or misconfigured certificate (relevant specifically for the passthrough approach), preventing traffic from being routed to a broken backend.

Choosing the Right Approach for Your Situation

Factor	Termination at LB	Passthrough
Certificate management complexity	Simple — one certificate	More complex — per-backend coordination
Internal traffic encryption	Unencrypted (relies on network isolation)	Fully encrypted end-to-end
Common use case	Most general web applications	Compliance-sensitive environments requiring end-to-end encryption

Common Errors

Backend server certificate expires independently, causing intermittent errors — a symptom of uncoordinated renewal across multiple backends in a passthrough setup; centralize the renewal and distribution process.

Continue Reading

Browse more articles in SSL/TLS & Certificates.

Vidensdatabase

Kategorier

Kategorier