Community Question Bundle
TLS Handshake and Certificate Chain Quiz
A 4-question reference set on TLS 1.3: the handshake flights, certificate chain validation, SNI privacy, and mTLS rotation. Covers the practical knobs that show up at staff-level networking interviews.
TLS Handshake and Certificate Chain Quiz
A 4-question reference set on TLS 1.3: the handshake flights, certificate chain validation, SNI privacy, and mTLS rotation. Covers the practical knobs that show up at staff-level networking interviews.
By CodeSnatch
April 3, 2026
·
Updated May 18, 2026
240 views
8
4.3 (14)
Walk through the TLS 1.3 handshake step by step. What does each side send, and at what point can the client start sending encrypted application data?
Examples
Example 1:
Input: Client opens a fresh TLS 1.3 connection to example.com
Output: 1-RTT before application data: ClientHello (with key share) -> ServerHello + cert + Finished -> Client Finished -> data
Explanation: TLS 1.3 reduces handshake to a single round trip vs TLS 1.2's two.Example 2:
Input: Resumed session with PSK (pre-shared key) from a recent connection
Output: 0-RTT: client can send application data in the very first flight
Explanation: 0-RTT trades replay resistance for latency and is opt-in per server policy.What does a certificate chain validation actually verify? Trace the signature checks from a leaf cert up to a trusted root.
Examples
Example 1:
Input: Client receives leaf cert (example.com) + intermediate (R3) from server; root (ISRG X1) in local trust store
Output: Verify chain: R3.sign(leaf) matches leaf.signature; X1.sign(R3) matches R3.signature; X1 in trust store -> ok
Explanation: Each cert is signed by the next one up; the root is self-signed and present in the OS trust store.Example 2:
Input: Server sends only the leaf cert, intermediate omitted
Output: Validation fails: client cannot link leaf signature to any root in its trust store
Explanation: Servers must send the full chain (minus the root); a missing intermediate breaks validation on first-touch clients.SNI (Server Name Indication) ships the requested hostname in the ClientHello. Why is it required for shared-IP hosting, and what privacy problem does it introduce?
Examples
Example 1:
Input: One IP hosts example.com and other-site.com under separate certificates
Output: Without SNI the server cannot pick the right cert; with SNI it sees 'example.com' and chooses correctly
Explanation: SNI was the protocol fix for IPv4 exhaustion that let many hostnames share one IP.Example 2:
Input: A passive network observer watches a TLS handshake
Output: Observer sees the SNI hostname in cleartext even though the rest of the handshake is encrypted
Explanation: SNI leaks the requested hostname; ECH (Encrypted Client Hello) is the in-progress fix.Mutual TLS (mTLS) requires both sides to present a certificate. What does the server validate on the client cert, and where does mTLS typically fail in production?
Examples
Example 1:
Input: Service mesh routes traffic between pods; both sides have certs from the mesh CA
Output: Each side validates the other's chain back to the mesh CA + checks the SPIFFE ID in SAN matches policy
Explanation: mTLS in a mesh provides authenticated identity for both endpoints, not just the server.Example 2:
Input: Client cert expires at midnight in a CD pipeline
Output: All outbound calls fail at 00:00 with 'certificate expired'; clock skew across nodes makes the failure look intermittent
Explanation: Cert rotation, not cryptography, is the dominant mTLS failure mode in production.