HTTPS — TLS handshake, certificates, CA: Worked examples

Definition Three notations you'll meet on this page

SNI = Server Name Indication — a field in the very first handshake message that tells the server which hostname you want, so a server hosting many sites can pick the right certificate. In classic TLS it travels in cleartext.
PRF = Pseudo-Random Function — a one-way "blender" that takes a secret plus some labelled inputs and outputs key material. Feed it the same inputs and you always get the same bytes out; but knowing the output tells you nothing about the secret. TLS uses it so both sides can independently compute identical keys without ever transmitting them. See Digital Signatures & Hashing for the one-way idea it relies on.
The concatenation bar $∥$ — when you see $r_{c} ∥ r_{s}$ , the bar just means "glue these two chunks of bytes end-to-end into one longer string." It is not division or absolute value; think of stapling $r_{c}$ 's bytes in front of $r_{s}$ 's bytes. Both sides staple in the same order, so both feed the PRF the identical input.

The scenario matrix

Every cell below is a class of thing that can happen in a TLS session. The worked examples that follow each carry a tag like [Cell A2] so you can see the whole grid is covered.

#	Cell class	What varies	Covered by
A1	Happy path	Everything valid	Ex 1
A2	Certificate chain arithmetic	Signature verify up the chain	Ex 2
B1	Degenerate: broken chain	Missing/untrusted issuer	Ex 3
B2	Degenerate: expired cert	`notAfter` in the past	Ex 4
B3	Degenerate: domain mismatch	SNI (Server Name Indication) ≠ cert Subject	Ex 5
C1	Active attacker (MITM)	Attacker substitutes public key	Ex 6
D1	Number-crunch: Diffie–Hellman	Small $p, g, a, b$ → shared secret	Ex 7
D2	Limiting behaviour: forward secrecy	Long-term key leaks later	Ex 8
E1	Real-world word problem	Latency / round trips	Ex 9
E2	Exam twist + 0-RTT edge case	"Which guarantee fails?"	Ex 10

Prerequisite threads if any cell feels shaky: TCP — three-way handshake, Symmetric vs Asymmetric Encryption, Diffie–Hellman Key Exchange, Digital Signatures & Hashing, Public Key Infrastructure (PKI), DNS, HTTP — methods, status codes.

Example 1 — The happy path [Cell A1]

Forecast: Will bulk page data be protected with the server's public key, or with something else?

Steps

Client → ClientHello with random nonce $r_{c}$ and cipher list. Why this step? Both sides must agree parameters and inject client randomness so the session key is unique (defeats replay).
Server → ServerHello picks a suite, sends $r_{s}$ ; then sends its cert chain (leaf + R3). Why? The chain lets the client authenticate and pull out the authentication public key.
Client verifies chain: leaf's signature checks against R3's public key; R3's signature checks against ISRG Root X1's public key (already trusted). Chain valid. Why? Trust is transitive through signatures — see the chain figure below.
Key exchange: client makes a pre-master secret, encrypts it with the leaf's public key, sends it. Why? Only the true shop.com holds the matching private key, so only it can decrypt → proves identity and shares a secret.
Both derive $master = PRF (pre_master, r_{c} ∥ r_{s})$ (recall the bar $∥$ just glues the two randoms into one input), then session keys, then ChangeCipherSpec + Finished. (Recall from the box above: $PRF$ is the one-way "blender" that turns the shared secret + both randoms into identical key bytes on each side, never sent over the wire.) Why? The Finished MAC over the whole transcript proves nobody tampered with the earlier cleartext messages.
Bulk HTTP now flows under a symmetric key (e.g. AES-GCM). Why? Symmetric crypto is far faster than asymmetric, so once the shared key is safely bootstrapped we switch to it for every byte of the page — the "hybrid" idea in action.

Figure — HTTPS — TLS handshake, certificates, CA

Figure walkthrough: the three boxes stack leaf → intermediate → root. The two black "signed by" arrows point upward: each certificate's signature is checked using the public key of the box above it. The red leaf box (shop.com) is the one you're trying to trust; the red arrow on the right shows your browser only accepts it because that upward path ends at the pre-trusted root. Cut any arrow and trust collapses.

Verify: The public key from the cert was used once, to bootstrap. Bulk data uses the derived symmetric key — matching the parent's "hybrid" idea. Forecast answer: something else (the symmetric key), not the public key. ✓

Example 2 — Chain signature arithmetic [Cell A2]

Forecast: Will the recovered $h^{'} = σ^{e} mod n$ come back to exactly $65$ ? (Here $σ$ denotes the signature value produced in step 1.)

Steps

Sign: $σ = 6 5^{413} mod 3233$ . Why? The CA signs with its private exponent — only it can produce this.
Compute: $σ = 887$ . Why? This number rides inside the child cert as its signature.
Verify: $h^{'} = 88 7^{17} mod 3233$ . Why? Anyone with the public $(e, n)$ can undo the private-key step.
Compute: $h^{'} = 65$ . Since $h^{'} = h$ , the link is authentic. Why? Matching hashes mean the body was signed by the private-key holder and not altered, so the browser accepts this rung of the chain.

Why $d = 413$ is the right key: for RSA we need $e \cdot d \equiv 1 (mod λ (n))$ , where (from the definition box) $λ (3233) = lcm (52, 60) = 780$ . Check: $17 \cdot 413 = 7021 = 9 \cdot 780 + 1$ , so $17 \cdot 413 \equiv 1 (mod 780)$ . That congruence is exactly what makes signing and verifying cancel out.

Verify: $6 5^{413 \cdot 17} \equiv 65 (mod 3233)$ because $413 \cdot 17 \equiv 1 (mod λ (3233) = 780)$ . Round-trip returns the original hash. ✓

Example 3 — Broken chain (degenerate) [Cell B1]

Forecast: Strong encryption is present — does the connection succeed?

Steps

Client tries to build a path leaf → … → trusted root. Why? Authentication needs a link ending at a key baked into the browser.
The path stops at CorpCA, which no trusted root vouches for. No valid chain. Why? Trust is only transitive through signatures reaching a known root.
Browser aborts with SEC_ERROR_UNKNOWN_ISSUER before any bulk data. Why? Encryption without verified identity is hollow — a MITM could self-issue the same way.

Verify: Which of the three guarantees failed? Authentication. Confidentiality's cipher was fine but is worthless without knowing who you share it with — matches the "self-signed certs" mistake in the parent. ✓ (No number to check.)

Example 4 — Expired certificate (degenerate: time limit) [Cell B2]

Forecast: Do good signatures rescue an out-of-date cert?

Steps

Check the validity window: is today inside $[notBefore, notAfter]$ ? Why? Certs expire so a compromised-then-rotated key can't be reused forever.
$2024 - 06 - 01 > 2024 - 03 - 15$ → outside the window (78 days past expiry). Why? Days after notAfter are the exact degenerate case: crypto valid, time invalid.
Browser rejects: CERT_HAS_EXPIRED. Why? An expired cert may guard a key the owner has already retired, so trusting it would defeat the whole point of rotation — the browser refuses rather than gamble.

Verify: Days from 2024-03-15 to 2024-06-01 = 16 (rest of March) + 30 (April) + 31 (May) + 1 = 78 days past. Positive ⇒ expired. ✓

Example 5 — Domain mismatch (degenerate: SNI ≠ Subject) [Cell B3]

Forecast: A valid, trusted, in-date cert — surely it's fine?

Steps

Compare the hostname you asked for (SNI = login.shop.com) against the cert's SAN list. Why? A cert authenticates specific names; a valid signature on the wrong name still isn't you.
login.shop.com matches neither shop.com nor www.shop.com (no wildcard *.shop.com). Why? Exact/wildcard matching only — no substring or "same registrable domain" shortcut.
Reject: SSL_ERROR_BAD_CERT_DOMAIN. Why? Accepting a name the CA never vouched for would let any shop.com cert holder impersonate arbitrary subdomains, so the browser insists on an exact/wildcard match.

Verify: Guarantee that fails: authentication (right owner proven, wrong name). Had the SAN been *.shop.com, it would match. ✓

Example 6 — Active man-in-the-middle [Cell C1]

Forecast: She controls the wire — can she read your pre-master secret?

Steps

You verify the cert's signature chain up to a trusted root. Why? This is exactly the check that catches key substitution.
Mallory's cert is signed by her key, not by any CA in your trust store → no valid chain (same failure mode as Ex 3). Why? She cannot forge a CA signature (needs a CA private key she doesn't have).
Alternatively, if she strips down to a self-signed cert, browser rejects it. Either way handshake aborts; no pre-master is ever encrypted to her. Why? Because the pre-master is only sent after the cert passes verification — no verified key means the client never releases the secret.

Figure walkthrough: you (left) send a plain ClientHello (black arrow, rightward) toward bank.com, but Mallory in the middle answers first. The red arrow back to you is her fake cert carrying her own key. Follow the red text down the left: your CA check fails, so the red "handshake aborts" note is where the attack dies — Mallory never receives a pre-master secret. The red highlights exactly the two moving parts of the attack: the fake cert and the rejection that defeats it.

Verify: The one wall that stops MITM is the CA signature check, not the encryption itself. Remove CA verification and Mallory wins — confirming the parent's "cert solves who is the public key". ✓

Example 7 — Diffie–Hellman number-crunch [Cell D1]

Forecast: Will Alice's $B^{a}$ equal Bob's $A^{b}$ exactly?

Steps

Alice sends $A = g^{a} mod p = 5^{6} mod 23$ . Why? She never reveals $a$ ; only $g^{a}$ travels, and inverting it is the discrete-log problem.
$5^{6} = 15625$ , and $15625 mod 23 = 8$ . So $A = 8$ .
Bob sends $B = g^{b} mod p = 5^{15} mod 23 = 19$ . Why? Symmetric role — his secret stays hidden too.
Alice computes $s = B^{a} mod p = 1 9^{6} mod 23$ . Why? $B^{a} = (g^{b})^{a} = g^{ab}$ .
Bob computes $s = A^{b} mod p = 8^{15} mod 23$ . Why? $A^{b} = (g^{a})^{b} = g^{ab}$ — same exponent, so same result.
Both get $s = 2$ . Why? Because $g^{ab} = g^{ba}$ , the two independently computed numbers are forced to be identical — that shared value becomes the seed for the session key, and it never crossed the wire.

Figure walkthrough: Alice (left) and Bob (right) each keep a secret ( $a = 6$ , $b = 15$ ) that never leaves their box. The two black arrows across the middle are the only things on the wire: the public values $A = 8$ and $B = 19$ . Each raises the other's public value to their own secret; the two red arrows converge on the single red box at the bottom — the shared secret $s = 2$ that was never transmitted. The red box is the payoff: identical on both sides, invisible to any eavesdropper.

Verify: $1 9^{6} mod 23 = 8^{15} mod 23 = 5^{6 \cdot 15} mod 23 = 2$ . Both sides equal ⇒ shared secret established without ever sending it. ✓

Example 8 — Forward secrecy under a later key leak (limiting case) [Cell D2]

Forecast: A leaked long-term key — does one, both, or neither past session fall?

Steps

Case (a): the recorded pre-master was encrypted with the long-term public key. With the leaked private key, attacker decrypts the pre-master → derives session keys → reads the recording. Why? The session secret was permanently tied to a long-lived key, so cracking that key retroactively unlocks everything it ever protected.
Case (b): each side used a throwaway DH key discarded after the session. The shared secret $g^{ab}$ was never encrypted under the long-term key and the ephemeral $a, b$ no longer exist. Why? The long-term key only signed the handshake; it never protected the secret, so leaking it reveals nothing about $g^{ab}$ .
So attacker cracks (a) only. (b) has forward secrecy. Why? Deleting the ephemeral keys after use means past traffic has no surviving door left to force — that is precisely what "forward secrecy" buys you.

Verify: Only the RSA-transport session (1 of 2) is compromised — exactly why TLS 1.3 keeps only ECDHE/DHE suites. Count of broken sessions = 1. ✓ (Logic check in VERIFY.)

Example 9 — Round-trip latency word problem [Cell E1]

Forecast: Roughly how much does TLS 1.3 save — a little or nearly half?

Steps

One round trip $= 2 \times 40 = 80$ ms. Why? A round trip is there-and-back.
(a) TLS 1.2: TCP (1 RTT) + TLS (2 RTT) $= 3$ RTT $= 3 \times 80 = 240$ ms. Why? Classic TLS needs an extra flight to send the cert/key-exchange and confirm.
(b) TLS 1.3: TCP (1 RTT) + TLS (1 RTT) $= 2$ RTT $= 2 \times 80 = 160$ ms. Why? 1.3 folds the key share into ClientHello, saving a round trip.
Saving $= 240 - 160 = 80$ ms (one whole RTT). Why? Fewer waiting-for-the-other-side cycles directly translates to less startup delay, which is why 1.3 feels snappier on high-latency links.

Verify: $3 \cdot 80 = 240$ , $2 \cdot 80 = 160$ , difference $= 80$ ms. Saving equals exactly one RTT — as designed. ✓

Example 10 — Exam twist: "which guarantee fails?" + the 0-RTT edge case [Cell E2]

Forecast: Part 1 — did any TLS guarantee fail? Part 2 — is "send data immediately" free of risk?

Steps

Part 1 — confidentiality: traffic was encrypted to that server. Held. Why? A valid cert means a real AES tunnel was established.
Part 1 — integrity: no tamper on the wire. Held. Why? The Finished MAC and AEAD tags were valid.
Part 1 — authentication: the cert proved you reached the real owner of secure-paypa1.com — exactly who you unknowingly connected to. None of the three TLS guarantees failed; the failure was human/UX (look-alike domain), outside TLS's job. Why? TLS authenticates the domain in the cert, not the domain you meant to type — the mismatch lives in the human's eyes, not in the protocol.
Part 2 — 0-RTT count: early data rides in the first client flight, so first app byte needs only TCP (1 RTT) + 0 TLS round trips of waiting = 1 RTT = 80 ms (vs 160 ms for normal 1.3, 240 ms for 1.2). Why? Resumption keys from a previous session let the client encrypt data before the server replies, so no extra wait is needed.
Part 2 — what weakens: 0-RTT early data is replayable — an attacker can capture and resend that first request, and it is not forward-secret. So safety of the guarantees is conditional: only idempotent requests (e.g. GET, never a "transfer money" POST) should use 0-RTT. Why? No server round trip means no fresh server randomness bound to that data yet, so uniqueness/replay protection is lost for the early bytes.

Verify: Part 1 → TLS-guarantees-failed count = 0. Part 2 → 0-RTT first-byte = $1 \times 80 = 80$ ms, and it is exactly 80 ms faster than normal 1.3 (160 ms). ✓

Recall Quick self-test

A cert is validly chained and in date but issued for shop.com while you asked for login.shop.com — accept? ::: No — SAN/domain mismatch; authentication fails (unless SAN is *.shop.com). With DH params $p = 23, g = 5, a = 6, b = 15$ , what is the shared secret? ::: $s = 2$ . Long-term key leaks next year; which past session is still safe — RSA transport or ECDHE? ::: ECDHE (forward secrecy). Under 80 ms RTT, how much does TLS 1.3 save vs TLS 1.2? ::: One RTT = 80 ms (160 ms vs 240 ms). Why should a "transfer money" request never use TLS 1.3 0-RTT? ::: 0-RTT early data is replayable and not forward-secret, so only idempotent requests are safe.