TLS — Handshake, Certs, mTLS & Termination
TLS gives HTTP confidentiality, integrity, and server authentication, plus client authentication when you ask for mTLS. Backend interviews are about handshake cost, certificate fields, and where the session ends.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
How many round trips is a TLS 1.3 full handshake?
Answer
One. TLS 1.2 was typically two before session resumption.
L2
What is ALPN?
Answer
A TLS extension that selects the application protocol, such as h2 or http/1.1, during the handshake.
L3
What must a server certificate satisfy?
Answer
The hostname is in the SAN, the chain reaches a trusted root, the dates are valid, and EKU allows serverAuth.
L4
Edge termination versus end-to-end?
Answer
The edge offloads public clients. If the path behind it is untrusted, re-encrypt or require mTLS. Do not send cleartext across a network you do not trust.
L5
Does mTLS replace OAuth or user sessions?
Answer
No. mTLS authenticates the calling workload. Users and delegated authority still need their own credentials.
L6
What is a SAN?
Answer
Subject Alternative Name. DNS names for servers, or a URI name such as a SPIFFE id for workload certificates.
L7
How do you avoid expiry outages?
Answer
Automate issuance, renew early, monitor notAfter, and overlap the old and new cert during rotation.
Failure modes
Incomplete chain
The server sends the leaf and forgets the intermediate. Some desktop browsers fetch it. Many phones and service clients do not.
Name mismatch
Clients dial an IP or a different hostname than the SAN. The handshake fails closed, which is what you want.
Clock skew
notBefore is in the future relative to a skewed client, so a brand-new certificate looks invalid.
Plaintext port left open
mTLS on 443 does nothing for a second port that still speaks cleartext HTTP.
Misconceptions
TLS 1.3 always takes as many round trips as TLS 1.2.
A full TLS 1.3 handshake is one RTT. 0-RTT is an extra early-data mode on resumption, not the normal full handshake.
Terminating at the load balancer means the request is safe the rest of the way.
It means the edge saw plaintext. The next hop needs its own trust story.
mTLS is user login.
It is peer authentication of a workload certificate. Application authorization is separate.
Interviewer traps
Designing ALB versus NLB, or an Ingress class, from a handshake question.
Name the trust boundary, then point at L4 versus L7 and the private-networking page.
Re-teaching SPIFFE and workload identity end to end.
Say the cert can carry a workload id, then send the listener to the service-to-service mTLS page.
Design scenario
Same prompt for every reader.
Requirements
Public clients verify a public name. The origin is not cleartext on an untrusted network. Service calls authenticate the peer workload. User auth stays in the app.
Traffic / scale
Short RPCs, so a full handshake on every call would dominate.
Latency
Repeat calls resume. First calls pay one TLS 1.3 round trip, or one QUIC round trip at the edge.
Consistency
A rotated certificate overlaps the old one so in-flight handshakes still verify.
Availability
Expiry and a missing intermediate alert before the outage.
Failure assumptions
- An intermediate is omitted from the handshake.
- A client clock is five minutes behind.
- A debug port speaks cleartext beside the TLS listener.
Constraints
- Do not redesign the edge anycast or the L4 versus L7 fleet.
- Do not treat mTLS as the user login.
Prompt
Public mobile clients hit a CDN. The origin sits in a VPC. Two internal services call each other and need workload identity. Users still log in with sessions.
API
Which listener is public TLS, and which is internal mTLS?
Data
Which certificate fields do you alert on?
Architecture
Where is plaintext visible, and why is that hop trusted?
Who is allowed to see plaintext
Prefer
A named trust boundary on every hop
Public clients stop at an edge that holds a public certificate. The next hop is either inside a network you trust, encrypted again, or mutually authenticated.
- One public name, automated renewal, OCSP stapling at the edge.
- Internal calls present a client certificate when policy demands workload identity.
- User sessions stay in the application even when the socket is mTLS.
Alternative
Terminate once and hope
Cleartext after the edge is fine only on a hop you already trust. Leaving a plaintext debug port open undoes the mutual-auth listener beside it.
- A diagram that says TLS and a packet capture that says HTTP.
- A client certificate treated as a user login.
- A leaf certificate with no intermediate in the handshake.
What a backend must be able to walk
Rounds, name, chain, then the hop where you intentionally decrypt.
- 1
Count the round trips
TLS 1.3 full handshake is one RTT. TLS 1.2 was often two. 0-RTT sends early data on resumption and can be replayed. QUIC folds this into the transport handshake. - 2
Check the certificate
SAN matches the name the client dialed. The chain reaches a root the client trusts. Dates cover now. EKU is serverAuth, plus clientAuth on a client cert. - 3
Pick the termination hop
Edge for public clients. Re-encrypt or mTLS when the next network is untrusted. App-native TLS only when you accept certs on every instance. - 4
Do not confuse mTLS with AuthN for users
The certificate names the workload. Sessions and tokens name the user. Both can be required. Neither replaces the other.
Overview
TLS is why an HTTPS call can trust the name in the URL and why a passive observer cannot read the body. Backend interviews rarely want the cipher suite list. They want how many round trips, which certificate fields fail a phone, where you decrypt, and what mTLS does not authorize.
HTTP/3 uses TLS 1.3 inside QUIC. This page is the handshake and the certificate, on TCP or inside QUIC. It is not a second copy of edge anycast, and it is not a second copy of workload identity.
Handshake
TLS 1.3 (RFC 8446) puts the key share in the first ClientHello. The server answers with ServerHello, the certificate, and Finished. The client can send application data with its Finished. That is one round trip for a full handshake.
TLS 1.2 typically needed two round trips before application data, unless an older session resume shortened it. New deployments should not offer TLS 1.0 or 1.1. A client that can only speak those is a compatibility exception you write down, not a default.
ALPN (RFC 7301) is inside this handshake. The client offers h2 and http/1.1. The server picks one. HTTP/2 on the public internet shows up this way. HTTP/3 does not: the client learns about QUIC from Alt-Svc or an HTTPS record, then runs ALPN h3 inside QUIC. That split is the previous lesson.
0-RTT early data exists on TLS 1.3 resumption as well as on QUIC. The replay rule is the same. Idempotent reads only.
Decisions
- 1
ClientHello plus key share
- nextALPN h2 or http/1.1
- 2
ALPN h2 or http/1.1
- nextServerHello and cert
- 3
ServerHello and cert
- nextVerify chain and SAN
- 4
Verify chain and SAN
- nextChain trusted?
- ?
Chain trusted?
- YesFinished plus HTTP
- NoFail closed
- 6
Finished plus HTTP
- 7
Fail closed
Lesson map
TLS — Handshake, Certs, mTLS & Termination
TLS gives HTTP confidentiality, integrity, and server authentication, plus client authentication when you ask for mTLS. Backend interviews are about handshake cost, certificate fields, and where the session ends.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["ClientHello plus key share"] b["ALPN h2 or http/1.1"] c["ServerHello and cert"] d["Verify chain and SAN"] a -->|ClientHello plus key share| b b -->|ALPN h2 or http/1.1| c c -->|ServerHello and cert| d
Session tickets or PSKs skip the full handshake on the next connection. Tickets are often local to the server that minted them, so a later connection to a different task pays the full handshake unless tickets are shared or the client lands on the same task. At high QPS the edge is where you want that CPU. Resumption does not fix a tiny connection pool. The next lesson owns the pool.
Certificates
| Field | What fails if it is wrong |
|---|---|
| SAN | The client dialed a name the certificate does not list. Common Name alone is not the modern check. |
| Chain | Intermediates were not sent. The client cannot build a path to a trusted root. |
| notBefore / notAfter | Expiry, or a clock skew that makes a new cert "not yet valid." |
| Public key | Prefer a modern curve such as ECDSA P-256, or RSA 2048 and up. Do not invent a smaller key to save CPU. |
| EKU | serverAuth for the server. clientAuth on certificates you expect clients to present. |
Issue with ACME or a cloud certificate manager. In clusters, a controller that renews before notAfter beats a calendar reminder. Alert on days remaining, not on the outage.
OCSP stapling attaches a fresh revocation proof to the handshake. Clients then skip a separate lookup. That saves a round trip and avoids telling a third party which site the user opened. Stapling is an edge feature worth turning on. It is not a substitute for short-lived certificates and automated renewal.
Where termination belongs
Decisions
- 1
Who must see plaintext?
- Edge policyTerminate at CDN
- Untrusted hopWorkload certs?
- 2
Terminate at CDN
- nextWrite the trust boundary
- ?
Workload certs?
- YesmTLS per hop
- NoRe-encrypt to the app
- 4
mTLS per hop
- nextWrite the trust boundary
- 5
Re-encrypt to the app
- nextWrite the trust boundary
- 6
Write the trust boundary
| Pattern | Use it when | What this page will not design |
|---|---|---|
| Edge only | Public sites, cacheable responses, WAF at the edge | Anycast and POP layout. See TLS at the edge. |
| Edge plus re-encrypt | The network after the edge is shared or untrusted | ALB versus NLB versus an Ingress class. See L4 versus L7 and private networking. |
| Mesh mTLS | You want hop-by-hop workload identity | Sidecar injection and gateway tradeoffs. See mesh architecture and mesh versus library versus gateway. |
| App-native TLS | A compliance rule says the process holds the keys | How the certificate is issued as a workload id. See service-to-service mTLS. |
Two certificate planes means two renewal clocks. Write both down.
mTLS, only the part this series owns
Mutual TLS means the client certificate is requested and checked. The server maps a name from that certificate, often a URI SAN, to a workload. You get a strong binding between the process and the socket.
You do not get user identity, and you do not get fine-grained authorization. A stolen user token over mTLS is still a stolen user token. A mesh that injects mTLS does not review your application checks.
Pros: the peer on the wire is a workload you enrolled, and a passive attacker cannot replay the bytes.
Cons: issuance, rotation, and trust bundles. The operational identity system is the service-to-service mTLS lesson. Compare sidecar-injected sockets with a library in the mesh tradeoff page. This page stops at "the certificate is the workload, the session is the user."
Failure modes worth listing out loud
- Incomplete chain. Desktops sometimes fetch the missing intermediate. Mobile clients and server HTTP libraries usually fail.
- Name mismatch. Dialing an IP that is not in the SAN fails. Add the name you actually dial, or dial the name on the certificate.
- Clock skew.
notBeforein the future relative to the client. - Expired intermediate. The leaf was renewed. The intermediate was not.
- Downgrade. Old clients negotiating TLS 1.0 because you left it enabled.
- A cleartext port beside the TLS port. mTLS on one listener does not cover the other.
Sandbox: decide, do not dial
The page sandbox cannot open node:tls or read a secret from disk. The check below is the interview version of ssl.getpeercert.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
A CDN terminates the public certificate and forwards HTTP to the origin over the public internet. What is missing, and which of the four patterns above fixes it without a lecture on load-balancer products?
Interview Q&A
How do TLS 1.3 and TLS 1.2 compare on round trips?
Answer
A full TLS 1.3 handshake is one round trip because the client sends a key share immediately. A full TLS 1.2 handshake is typically two. Resumption and 0-RTT are extra modes, and 0-RTT can be replayed.
What is ALPN?
Answer
Application-Layer Protocol Negotiation. The client lists protocol ids in the ClientHello and the server picks one, usually h2 or http/1.1, before HTTP bytes flow. HTTP/3 uses ALPN h3 on the QUIC handshake after the client has discovered QUIC some other way.
When do you terminate at the edge instead of end to end?
Answer
Terminate at the edge when you want offload, a WAF, or a CDN in front of public clients. Re-encrypt or use mTLS if anything after that edge is untrusted or the policy says the workload must authenticate. "The load balancer already decrypted" is not a trust proof. Product-specific edge and proxy designs live on the anycast and L4 versus L7 pages.
Does mTLS replace OAuth or a user session?
Answer
No. mTLS authenticates the workload that opened the socket. OAuth and session cookies authenticate a user or a delegated client. You often want both. The identity issuance details are on the service-to-service mTLS page.
What is a SAN?
Answer
Subject Alternative Name. For a public server it is the DNS name clients must match. For workload certificates it is often a URI. Matching only the old Common Name field is how you fail a strict client.
How do you avoid certificate expiry outages?
Answer
Automate issuance and renewal, alert on days until notAfter, and overlap the new certificate with the old one so handshakes in flight still chain. An intermediate has an expiry too.
Why does OCSP stapling matter?
Answer
The server attaches a signed revocation answer to the handshake. Clients avoid an extra round trip and avoid asking a third party about the site. Pair it with short lifetimes. Stapling is not renewal.