What is SSL/TLS Termination and Where Should It Happen?
Learn what SSL/TLS termination is, where it happens, and why internal traffic needs re-encryption for compliance — with an interview-ready answer.
Expected Interview Answer
SSL/TLS termination is the point in an infrastructure where encrypted HTTPS traffic is decrypted back into plain HTTP, typically at a load balancer, reverse proxy, or ingress controller, so that the certificate and private key management, and the CPU cost of decryption, are centralized rather than duplicated on every backend server.
Terminating TLS at the edge — a cloud load balancer (AWS ALB), an Nginx/Envoy reverse proxy, or a Kubernetes Ingress controller — means only that one component holds the certificate and private key, backend application servers receive plain HTTP, and renewing a certificate is a single operation instead of redeploying it to every instance. This simplifies operations and offloads the computationally expensive TLS handshake from application servers, but it means traffic between the load balancer and backend travels unencrypted unless "TLS re-encryption" (also called SSL passthrough with a second termination, or end-to-end TLS) is explicitly configured for that hop too — a requirement in zero-trust or regulated environments like PCI-DSS or HIPAA workloads. Service meshes like Istio or Linkerd solve this by automatically re-encrypting internal pod-to-pod traffic with mutual TLS (mTLS) even after the initial edge termination, giving both centralized certificate management at the edge and encryption-in-depth internally. The choice ultimately balances operational simplicity (terminate once, at the edge) against defense-in-depth (encrypt every hop, accepting more certificate and performance overhead).
- Centralizes certificate management to one component instead of every server
- Offloads expensive TLS handshake CPU cost from application servers
- Simplifies certificate renewal and rotation operationally
- Can be combined with mTLS/service mesh for full end-to-end encryption when required
AI Mentor Explanation
SSL/TLS termination is like a single accredited security checkpoint at the stadium entrance that unseals and inspects every sealed courier package before it is handed to the relevant department inside, rather than every single department having to unseal packages themselves. Centralizing the unsealing at one checkpoint means only that one team needs training and equipment to handle seals, instead of every department maintaining that capability. If the stadium wants extra assurance, it can re-seal packages before sending them onward to sensitive departments like the medical room, mirroring end-to-end re-encryption. Most departments, though, are fine trusting that once past the checkpoint, the package is safe internally.
Step-by-Step Explanation
Step 1
Install the certificate at the termination point
Attach the TLS certificate and private key to the load balancer, reverse proxy, or Ingress controller — not every backend server.
Step 2
Client establishes TLS with the edge
The client performs the TLS handshake with the terminating component, which decrypts incoming HTTPS traffic.
Step 3
Forward as plain HTTP (or re-encrypt) internally
The terminator sends plain HTTP to backends, or re-encrypts with a second TLS session/mTLS if internal encryption is required.
Step 4
Automate renewal centrally
Use a tool like cert-manager or ACM to auto-renew the certificate at the single termination point rather than redeploying to every server.
What Interviewer Expects
- Clear definition of what “termination” means (decrypting back to plain HTTP)
- Understanding of why centralizing certs at the edge simplifies operations
- Awareness that internal traffic post-termination is plaintext unless re-encrypted
- Knowledge of mTLS/service mesh as the solution for end-to-end encryption
Common Mistakes
- Assuming HTTPS is still encrypted between the load balancer and backend by default
- Installing certificates on every backend server unnecessarily
- Forgetting compliance requirements (PCI-DSS, HIPAA) may mandate encryption on every hop
- Confusing TLS termination with TLS passthrough (where the LB does not decrypt at all)
Best Answer (HR Friendly)
“TLS termination means we decrypt HTTPS traffic at one central point, usually our load balancer or ingress, instead of every single server having to manage its own certificate. That keeps certificate renewal and encryption overhead in one place, but it also means we need to explicitly re-encrypt traffic internally, for example with a service mesh, whenever compliance or security requirements demand encryption all the way to the backend.”
Code Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- app.example.com
secretName: myapp-tls
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-svc
port:
number: 80Follow-up Questions
- What is the difference between TLS termination and TLS passthrough?
- How does a service mesh implement mTLS after edge termination?
- Why might a regulated workload require end-to-end TLS re-encryption?
- How does cert-manager automate certificate renewal at the termination point?
MCQ Practice
1. What does SSL/TLS termination mean?
Termination is the point where TLS-encrypted traffic is decrypted, typically at a load balancer, proxy, or ingress controller.
2. After TLS termination at a load balancer, is traffic to the backend server encrypted by default?
Once TLS is terminated, the traffic becomes plain HTTP internally unless a second TLS session or mTLS is explicitly set up.
3. What technology commonly provides automatic mTLS re-encryption for internal pod-to-pod traffic after edge termination?
Service meshes like Istio and Linkerd automatically wrap internal service-to-service traffic in mutual TLS, giving end-to-end encryption beyond the edge termination point.
Flash Cards
What is SSL/TLS termination? — The point where encrypted HTTPS traffic is decrypted back into plain HTTP.
Where does termination typically happen? — At a load balancer, reverse proxy, or Kubernetes Ingress controller.
Is traffic encrypted after termination by default? — No — it is plain HTTP internally unless re-encryption/mTLS is configured.
What commonly provides end-to-end encryption post-termination? — A service mesh (Istio, Linkerd) using mutual TLS between pods.