TLS Termination

TLS termination is the point in your network architecture where an encrypted TLS connection is decrypted. The device or service that terminates TLS holds the private key, performs the handshake with the client, and decrypts the traffic. Everything downstream of the termination point receives plaintext HTTP (unless re-encryption is configured). Understanding where TLS terminates is critical because it determines where certificates must be managed, where private keys are stored, and where visibility gaps exist.

Why it matters

• Certificate management scope — certificates must be deployed and renewed at every termination point. If TLS terminates at 50 load balancer instances, those 50 instances need the certificate and private key — not the backend application servers.
• Private key exposure surface — the private key exists wherever TLS terminates. Terminating at a CDN edge means the CDN provider holds your private key (or you use keyless SSL). This is a trust decision.
• Performance offloading — TLS handshakes are CPU-intensive (especially RSA). Terminating at dedicated hardware (F5, Citrix) or optimized proxies (Nginx, Envoy) frees application servers from cryptographic overhead.
• Plaintext internal traffic — after termination, traffic is unencrypted on the internal network. If an attacker gains access to the internal network, they can sniff all post-termination traffic. This is why zero-trust architectures re-encrypt with mTLS between services.
• Header injection — the termination point typically adds headers (X-Forwarded-For, X-Forwarded-Proto) so backends know the original client used HTTPS. If these headers aren’t set correctly, applications may generate HTTP links or fail to enforce HTTPS redirects.

How it works

1. Client initiates TLS — connects to the public endpoint (e.g., api.example.com:443)
2. DNS resolves to termination point — typically a load balancer, CDN edge, or API gateway IP
3. Termination point performs handshake — presents the TLS certificate, negotiates cipher suite, derives session keys
4. Traffic decrypted — the termination point decrypts the request into plaintext HTTP
5. Forwarded to backend — plaintext request is sent to the application server over the internal network (port 80 or a private port)
6. Optional re-encryption — in some architectures, the termination point re-encrypts traffic to the backend using a separate internal certificate (TLS bridging)

In real systems

AWS ALB (most common pattern):

Client → HTTPS → ALB (terminates TLS, cert from ACM) → HTTP → EC2/ECS targets

The ALB holds the certificate (managed by ACM with auto-renewal). Backend targets receive plaintext on port 80. The ALB adds X-Forwarded-Proto: https so the application knows the original connection was encrypted.

Cloudflare CDN (edge termination):

Client → HTTPS → Cloudflare Edge (terminates TLS) → HTTPS → Origin Server

Cloudflare terminates TLS at their edge using either a Universal SSL certificate (Cloudflare-managed) or your uploaded certificate. Traffic to origin can be re-encrypted (Full Strict mode) or sent as plaintext (Flexible mode — dangerous).

Nginx reverse proxy:

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        proxy_pass http://backend:8080;  # Plaintext to backend
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Kubernetes Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-secret  # TLS terminates at ingress controller
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: app-service
            port:
              number: 80  # Backend receives plaintext

Where it breaks

Certificate monitored on wrong layer — the team monitors the certificate on the application server (port 8443), but TLS actually terminates at the load balancer (port 443 with a different certificate). The LB certificate expires, causing an outage, while monitoring shows the app cert is fine. Certificate discovery must scan all termination points — not just application endpoints.

CDN in Flexible mode — Cloudflare is configured with “Flexible SSL” — it terminates TLS at the edge but connects to the origin over plaintext HTTP. Users see a padlock in their browser, but traffic between Cloudflare and your server is unencrypted. An attacker on the network path between Cloudflare and your origin can intercept everything. Always use “Full (Strict)” mode with a valid origin certificate.

mTLS client certificate lost at termination — a client sends a client certificate for mTLS authentication. The load balancer terminates TLS and forwards the request to the backend as plaintext HTTP. The client certificate information is lost unless the LB explicitly forwards it via headers (X-Client-Cert). The backend receives an unauthenticated request and either rejects it (breaking the flow) or accepts it (bypassing authentication).

Operational insight

In multi-layer architectures, TLS can terminate and re-encrypt multiple times: CDN edge → regional load balancer → service mesh sidecar → application. Each hop has its own certificate with its own expiry. An outage at any layer looks the same to the end user (TLS error), but the root cause could be any of 3-4 different certificates. Effective certificate management requires a complete map of all termination points and their certificates — not just the edge-facing ones. Most organizations discover termination points they didn’t know existed only after an outage.

Related topics

• What is a TLS Certificate
• What is mTLS
• What is Certificate Discovery
• Certificate Monitoring and Alerting
• TLS Certificates in Kubernetes