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
- How to Set Up Basic Load Balancing with Nginx
- How to Install a Wildcard SSL Certificate with Certbot DNS Challenge
- How to Scale an E-commerce Site with Load Balancing
Browse more articles in SSL/TLS & Certificates.
