9.5 Public Key Infrastructure (PKI), Digital Certificates & TLS/SSL

Back to Computer Networks Notes

📚Module 09: Network Security & CryptographyTopic 9.5⏱️16 min read

🎯High-Yield For:Semester Exams (All Universities) • Placement Technical Rounds • Engineering Foundations

💡 Core Intuition: The Government Passport & Verification Chain

🍳 The Everyday Analogy: Proving Identity to Border Control

Imagine an individual arrives at an international border and announces: "I am the Ambassador of Canada; please allow me access to your military headquarters."

1. The Trust Deficit: The border agent has never met this person and cannot verify their word.
2. The Passport (Digital Certificate): The traveler hands over an official passport. Inside is their photograph and name (Subject Identity), along with a high-security cryptographic holographic seal (Digital Signature) stamped by the Canadian Passport Office (Certificate Authority).
3. The Embedded Trust Store: The border control computer does not need to call the Canadian President on the phone. The border agency already has the authentic public signature keys of all international passport offices pre-installed in its trusted computer registry (Root Trust Store). The agent validates the signature in seconds and grants entry.

💻 Bridging to Computer Science

In network security:

• When your browser connects to https://www.google.com, the remote server sends its public key. But how does your browser know that public key belongs to Google and not an eavesdropper sitting at a public coffee shop?
• Public Key Infrastructure (PKI) binds an identity (such as the domain name google.com) to a public key using an X.509 Digital Certificate signed by a trusted third party called a Certificate Authority (CA).
• Transport Layer Security (TLS) uses this certificate to authenticate the server, negotiate ephemeral symmetric keys, and encrypt all application-layer web traffic (HTTPS).

---

📑Table of Contents

• 📜 The X.509 Digital Certificate Architecture
  • Core Fields of an X.509 v3 Certificate
• 🌳 The PKI Hierarchical Chain of Trust
  • How Chain Verification Works in the Browser
• 🚫 Certificate Revocation: CRL vs OCSP vs OCSP Stapling
• 🤝 The Transport Layer Security (TLS) Handshake
  • The Modern TLS 1.3 Handshake (1-RTT Connection)
  • Perfect Forward Secrecy (PFS)
• 💻 Inspecting Certificates via OpenSSL
• 🏭 Real-World Production Context: Automated TLS, Certificate Transparency & OCSP Stapling
• 📐 Numerical Applications & Worked Examples
  • Example 1: X.509 Certificate Chain Path Validation & Key Hierarchy
  • Example 2: Handshake Latency Modeling: Cold TLS 1.2 vs Cold TLS 1.3 vs 0-RTT Resumption
  • Example 3: Revocation Economics: Traditional OCSP vs OCSP Stapling
• 🎯 Exam & Interview Pitfall Check

---

📜 The X.509 Digital Certificate Architecture

An X.509 certificate (governed by RFC 5280) is a standardized data structure containing an identity, a public key, and a cryptographic signature.

Core Fields of an X.509 v3 Certificate

Certificate Field	Standard Representation	Technical Purpose
Version	Integer (v3)	Declares X.509 standard version (v3 supports modern extensions).
Serial Number	Unique Hex String	Invariant identifier assigned by the issuing CA for revocation tracking.
Signature Algorithm	sha256WithRSAEncryption / ecdsa-with-SHA384	Cryptographic algorithm used by the CA to sign this certificate.
Issuer	C=US, O=Let's Encrypt, CN=R3	The Distinguished Name (DN) of the Certificate Authority that issued and signed the certificate.
Validity Period	Not Before / Not After	Timestamps specifying the exact validity window (typically 90 days to 1 year).
Subject	CN=binarydose.com	The entity whose public key is being certified (the server or organization).
Subject Public Key Info	Algorithm (RSA 2048-bit), Public Key Bits	The actual public key belonging to the Subject, used by clients to encrypt session keys or verify signatures.
Subject Alternative Name (SAN)	DNS:binarydose.com, DNS:*.binarydose.com	Crucial Extension: The list of all hostnames and wildcards authorized to use this certificate.
CA Digital Signature	Encrypted hash string	The SHA-256 hash of all above fields encrypted with the CA's Private Key.

---

🌳 The PKI Hierarchical Chain of Trust

Browsers do not have millions of individual server certificates hardcoded into their memory. Instead, trust is established through a hierarchical delegation chain:

The X.509 Cryptographic Chain of Trust

Hierarchical delegation linking leaf web server certificates back to pre-installed Root CAs

Apex: Trust Anchor

Root Certificate Authority (Root CA)

🏛️

Self-signed certificate (Issuer == Subject). Private key held in an offline, air-gapped Hardware Security Module (HSM).

DigiCert Global RootISRG Root X1 (Let's Encrypt)Pre-installed in OS/Browser Trust Store

↓Signs Intermediate CA Certificate

Tier 2: Delegated Issuer

Intermediate Certificate Authority

🏢

Signed by the Root CA. Conducts high-volume daily automated certificate issuance without exposing Root keys.

Let's Encrypt R3Cloudflare Inc ECC CA-3Can be revoked if an issuance server is breached

↓Signs End-Entity Server Certificate

Leaf: Web Server

Leaf / End-Entity Certificate

🌐

Installed on web servers (e.g. binarydose.com). Validated by browsers during the TLS handshake.

Basic Constraints: CA=FALSEContains server public keyBinds domain name in SAN

↓Delivered to Browser in ServerHello

Client Endpoint

Web Browser / Operating System

💻

Validates digital signatures upward along the chain until hitting a pre-trusted Root CA in its local Trust Store.

Verifies signature mathematicsChecks SAN domain matchChecks certificate expiration dates

How Chain Verification Works in the Browser

When you visit https://www.binarydose.com:

1. The server presents its Leaf Certificate along with the Intermediate CA Certificate.
2. The browser inspects the Leaf Certificate:
   • Has it expired? (Current Time must be between Not Before and Not After).
   • Does the URL hostname match the Subject Alternative Name (SAN)?
3. The browser extracts the signature on the Leaf Certificate and uses the Intermediate CA's Public Key to verify that the Intermediate CA signed it.
4. The browser then inspects the Intermediate Certificate and verifies its signature using the Root CA's Public Key.
5. The browser checks its local, pre-installed Root Trust Store (maintained by Microsoft Windows, Apple macOS, Google Chrome, or Mozilla Firefox).
6. Because the Root CA is explicitly trusted, the entire chain is cryptographically proven, and the green padlock activates!

---

🚫 Certificate Revocation: CRL vs OCSP vs OCSP Stapling

If a server's private key is leaked or stolen, the certificate must be revoked before its expiration date.

Certificate Revocation Mechanisms: Evolution

From bandwidth-heavy static lists to privacy-preserving server-side OCSP stapling

Legacy Pull

CRL & Standard OCSP

⚠️

Dominant Architecture / DomainClient-Queried Revocation Checks

• •Certificate Revocation List (CRL): Browser periodically downloads massive multi-megabyte lists of revoked serial numbers from the CA.
• •Online Certificate Status Protocol (OCSP): Browser queries CA responder in real time: 'Is serial #12345 revoked?'
• •Privacy Leak: The CA learns every website the user visits in real time!
• •Latency Hit: Adds an extra network round trip before every new website connection.

"Inefficient and leaks client browsing history to third-party CAs."

Modern Standard

OCSP Stapling (RFC 6066)

🛡️

Dominant Architecture / DomainServer-Cached Signed Status Assertion

• •The web server queries the CA's OCSP responder itself every few hours.
• •The CA returns a cryptographically signed, timestamped proof of validity.
• •The web server 'staples' this signed OCSP response directly inside its TLS handshake.
• •Browser verifies CA signature instantly with zero external network requests and zero privacy leakage.

"Fast, zero-latency, and 100% privacy-preserving revocation validation."

---

🤝 The Transport Layer Security (TLS) Handshake

Originally developed as Secure Sockets Layer (SSL) by Netscape, the protocol was renamed TLS when standardized by the IETF.

• SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 are cryptographically broken and strictly deprecated.
• Modern web security relies on TLS 1.2 (RFC 5246) and TLS 1.3 (RFC 8446).

---

The Modern TLS 1.3 Handshake (1-RTT Connection)

In 2018, TLS 1.3 completely overhauled the handshake protocol:

1. Speed: Reduced connection setup latency from $2 \times RTT$ down to $1 \times RTT$ (and $0 \times RTT$ for resumed connections).
2. Security: Completely eliminated obsolete, dangerous primitives: RSA key exchange, static Diffie-Hellman, CBC mode ciphers, RC4, MD5, and SHA-1.
3. Mandatory Forward Secrecy: All key exchanges must use Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).

Space-Time Protocol Ladder

Step 1 of 5

The TLS 1.3 1-RTT Handshake Protocol

Space-time protocol exchange establishing authenticated, encrypted communication in a single round trip

💡Click or hover any packet flight arrow, timer event, or step button to inspect protocol mechanics in real time

💻Initiator

Web Browser (Client)

Lifeline Rail (t ↓)

🏢Target

Web Server (Host)

Lifeline Rail (t ↓)

11. ClientHello(Ciphersuites + Key Share (g^a))

22. ServerHello(Chosen Cipher + Key Share (g^b))

33. Encrypted Extensions & Certificate(X.509 Chain + Signed Signature)

44. Server Finished(HMAC of entire handshake)

55. Client Finished & Application Data(HTTP GET Request (Encrypted))

Step 1 of 5client ➔ server✅ Delivered Successfully1. ClientHello

Client sends supported ciphersuites and precomputes its ephemeral Diffie-Hellman key share (g^a).

---

Perfect Forward Secrecy (PFS)

In legacy TLS 1.2 with RSA key exchange:

• The client encrypted a random pre-master secret using the server's public RSA key and sent it over the wire.
• If an adversary recorded all encrypted network traffic for 10 years, and later broke into the server's data center and stole the server's private RSA key, the adversary could decrypt all 10 years of historical recorded traffic retroactively!

How TLS 1.3 Guarantees PFS:

• Key exchange is performed strictly using Ephemeral Diffie-Hellman (ECDHE).
• Alice and Bob generate temporary private keys ($a, b$) used only for that single session.
• Once the session terminates, the ephemeral keys are securely erased from RAM.
• Even if an attacker steals the server's long-term certificate private key, they cannot decrypt past recorded sessions, because the ephemeral keys that generated the session keys no longer exist anywhere on Earth!

---

💻 Inspecting Certificates via OpenSSL

# Connect to a remote server and display the entire X.509 certificate chain
openssl s_client -connect www.google.com:443 -servername www.google.com

# Inspect and parse a local certificate file in human-readable format
openssl x509 -in cert.pem -text -noout

---

🏭 Real-World Production Context: Automated TLS, Certificate Transparency & OCSP Stapling

Modern internet security operations rely on high-velocity automated certificate lifecycles:

• Automated TLS via Let's Encrypt & The ACME Protocol (RFC 8555):
  • Prior to 2015, purchasing an SSL certificate cost hundreds of dollars and required days of manual verification, resulting in only ~30% of web traffic being encrypted.
  • Let's Encrypt introduced the Automated Certificate Management Environment (ACME) protocol. Web servers (running certbot or native Caddy/Traefik daemons) prove domain control automatically via HTTP-01 (serving a cryptographic token at /.well-known/acme-challenge/) or DNS-01 (creating a _acme-challenge TXT record).
  • Certificates have short 90-day lifespans, forcing organizations to automate renewal cron jobs and eliminating the risk of neglected multi-year certificates with compromised keys. Today, over 90% of global web page loads use HTTPS.
• Certificate Transparency (CT) Merkle Logs & Rogue CA Detection:
  • In 2011, Dutch CA DigiNotar was breached by adversaries who forged wildcard certificates for *.google.com, allowing state actors to intercept communications of 300,000 users.
  • The industry responded with Certificate Transparency (RFC 6962). CAs must submit all issued certificates to multiple independent, append-only cryptographic Merkle tree logs.
  • Google Chrome and Apple Safari enforce CT: every presented certificate must contain Signed Certificate Timestamps (SCTs) proving public logging. Domain owners monitor CT log streams in real-time to detect fraudulent certificates issued for their domains within seconds.
• Production OCSP Stapling in NGINX & Cloudflare:
  • Traditional client-side OCSP checks leak user browsing destinations to third-party CAs and delay page loads by $100\text{ ms} - 300\text{ ms}$.
  • High-performance edge reverse proxies enable OCSP Stapling:

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/certs/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

  • NGINX queries the CA's OCSP server asynchronously every few hours, caches the cryptographic proof, and "staples" it directly into the TLS CertificateStatus handshake message. The browser verifies the CA signature locally in $0\text{ ms}$ with zero third-party tracking.

---

📐 Numerical Applications & Worked Examples

Example 1: X.509 Certificate Chain Path Validation & Key Hierarchy

Problem Statement: A web browser establishes a connection to https://api.fintech.io and receives a certificate chain comprising three certificates:

• Leaf Certificate ($C_1$): Subject CN=api.fintech.io, Issuer CN=Fintech Intermediate CA G2, Signature Algorithm: sha256WithRSAEncryption.
• Intermediate Certificate ($C_2$): Subject CN=Fintech Intermediate CA G2, Issuer CN=GlobalTrust Root CA, Signature Algorithm: ecdsa-with-SHA384.
• Root Certificate ($C_3$): Subject CN=GlobalTrust Root CA, Issuer CN=GlobalTrust Root CA, self-signed.

1. Specify which certificate's public key is used to cryptographically verify the signature of $C_1$, $C_2$, and $C_3$.
2. Suppose an attacker attempts to sign a fraudulent certificate $C_{\text{phish}}$ (CN=bank.com) using the private key corresponding to Leaf Certificate $C_1$. Explain which X.509 extension prevents the browser from accepting $C_{\text{phish}}$.
3. Explain why the web server MUST transmit $C_1$ and $C_2$ during the TLS handshake, but SHOULD NOT transmit $C_3$.

Step-by-Step Solution:

1. Public Key Verification Mapping:
   • Leaf Certificate ($C_1$): The signature on $C_1$ was produced by the issuing intermediate CA. The browser verifies $C_1$'s signature using the Public Key of Intermediate Certificate ($C_2$).
   • Intermediate Certificate ($C_2$): The signature on $C_2$ was produced by the Root CA. The browser verifies $C_2$'s signature using the Public Key of Root Certificate ($C_3$).
   • Root Certificate ($C_3$): Being self-signed, its signature verifies against its own public key. However, cryptographic verification of a self-signature proves nothing about trust. $C_3$ is trusted exclusively because its exact hash/byte sequence matches a pre-installed Root CA in the client's local OS/Browser Trust Store.
2. The BasicConstraints Extension Defense:
   • In X.509 v3 (RFC 5280), the BasicConstraints extension defines whether a certificate subject can act as a Certificate Authority: $\text{BasicConstraints} = \{\text{cA}: \text{BOOLEAN}, \ \text{pathLenConstraint}: \text{INTEGER}\}$
   • For Leaf Certificate $C_1$, the issuing CA strictly configured cA: FALSE.
   • When the browser's path validation algorithm examines the signature on $C_{\text{phish}}$, it observes that the signing certificate ($C_1$) has cA: FALSE.
   • RFC 5280 mandates that leaf entities cannot sign other certificates. The client immediately aborts the connection with ERR_CERT_INVALID or CERT_CHAIN_UNTRUSTED.
3. Wire Transmission Optimization:
   • The client has no prior knowledge of the newly issued $C_1$ or intermediate $C_2$; therefore, the server must supply both to allow the client to build the chain path.
   • However, the client already possesses Root $C_3$ inside its pre-installed trust store.
   • Transmitting $C_3$ over the wire wastes $1\text{ to }2\text{ KB}$ of bandwidth, causing the initial TLS handshake flight to spill into extra TCP packets (violating initial congestion window $10 \times \text{MSS}$ limits). Modern web servers omit the root certificate to minimize latency.

---

Example 2: Handshake Latency Modeling: Cold TLS 1.2 vs Cold TLS 1.3 vs 0-RTT Resumption

Problem Statement: A mobile application in Singapore communicates with a cloud backend in Frankfurt across an intercontinental link with Round-Trip Time $RTT = 180\text{ ms}$. The standard TCP 3-way handshake consumes $1 \times RTT$.

1. Compute the total elapsed latency before the application receives the first byte of HTTP data under a cold TLS 1.2 connection (2-RTT handshake followed by 1-RTT HTTP request/response).
2. Compute the total elapsed latency under a cold TLS 1.3 connection (1-RTT handshake followed by 1-RTT HTTP request/response).
3. Compute the total latency under a warm TLS 1.3 connection using 0-RTT Session Resumption (Early Data via PSK with TCP Fast Open).
4. Calculate the percentage latency reduction achieved by TLS 1.3 0-RTT compared to cold TLS 1.2.

Step-by-Step Solution:

1. Cold TLS 1.2 Latency ($4 \times RTT$):
   • TCP 3-Way Handshake: $1 \times RTT = 180\text{ ms}$.
   • TLS 1.2 Handshake (ClientHello $\to$ ServerHello/Cert $\to$ ClientKeyExchange $\to$ Finished): $T_{\text{TLS1.2}} = 2 \times RTT = 2 \times 180\text{ ms} = 360\text{ ms}$
   • Application Data Exchange (HTTP GET $\to$ First Byte): $T_{\text{HTTP}} = 1 \times RTT = 180\text{ ms}$
   • Total Latency: $T_{\text{cold\_1.2}} = 180 + 360 + 180 = \mathbf{720\text{ ms}}$
2. Cold TLS 1.3 Latency ($3 \times RTT$):
   • TCP Handshake: $1 \times RTT = 180\text{ ms}$.
   • TLS 1.3 Handshake (Client sends ClientHello + DH Key Share; Server responds ServerHello + Cert + Finished): $T_{\text{TLS1.3}} = 1 \times RTT = 180\text{ ms}$
   • Application Data Exchange: $1 \times RTT = 180\text{ ms}$.
   • Total Latency: $T_{\text{cold\_1.3}} = 180 + 180 + 180 = \mathbf{540\text{ ms}}$
3. Warm TLS 1.3 with 0-RTT & TCP Fast Open ($1 \times RTT$):
   • With TCP Fast Open (TFO), the TCP SYN carries the TLS ClientHello and pre-shared key ticket (early_data).
   • The client transmits its encrypted HTTP GET request in the very first flight without waiting for the server: $T_{\text{setup}} = 0\text{ ms}$
   • The server receives the SYN + Early Data, decrypts the HTTP request, processes it, and returns the TCP SYN-ACK + ServerHello + HTTP response in a single return flight: $T_{\text{response}} = 1 \times RTT = 180\text{ ms}$
   • Total Latency: $T_{\text{0-RTT}} = \mathbf{180\text{ ms}}$
4. Percentage Latency Reduction: $\text{Reduction} = \frac{T_{\text{cold\_1.2}} - T_{\text{0-RTT}}}{T_{\text{cold\_1.2}}} \times 100\% = \frac{720 - 180}{720} \times 100\% = \mathbf{75.0\%}$ The user perceives the connection as four times faster, dropping wait time from nearly three-quarters of a second down to a single network hop!

---

Example 3: Revocation Economics: Traditional OCSP vs OCSP Stapling

Problem Statement: A news portal receives $R = 25,000\text{ new TLS connections/second}$.

• Under client-side OCSP querying, each browser independently issues an HTTP request to the issuing CA's OCSP responder. The average OCSP network latency is $T_{\text{OCSP}} = 140\text{ ms}$.
• 0.8% of client-side OCSP queries experience timeouts or network packet drops, stalling for a timeout threshold of $T_{\text{timeout}} = 2,500\text{ ms}$.

1. If the browser enforces an OCSP Hard-Fail policy, how many legitimate user requests fail per second?
2. If the browser falls back to an OCSP Soft-Fail policy, detail the active exploit scenario that leaves users vulnerable to Man-in-the-Middle attacks.
3. If the web cluster deploys OCSP Stapling with a validity assertion cached for $T_{\text{cache}} = 12\text{ hours}$ across 10 edge servers, calculate the total daily OCSP requests sent to the CA, and compute the resulting client latency overhead.

Step-by-Step Solution:

1. OCSP Hard-Fail Failure Rate:
   • Under hard-fail, any dropped or timed-out OCSP check causes the browser to terminate the TLS session.
   • Failed requests per second: $\text{Failures} = 25,000 \times 0.008 = \mathbf{200\text{ failed sessions/sec}}$
   • Over an hour, $720,000$ legitimate visitors encounter fatal connection errors, which is why browser vendors historically refused to enable hard-fail by default.
2. OCSP Soft-Fail Security Vulnerability:
   • Under soft-fail, if the OCSP query times out or fails to connect, the browser assumes the certificate is valid and connects anyway.
   • Active Attacker Exploit: An adversary steals the server's private key. When intercepting a victim's network traffic, the attacker simultaneously drops or blackholes all outbound packets directed to the CA's OCSP responder IP address.
   • The victim's browser queries the OCSP responder, waits for the timeout, soft-fails, and happily accepts the revoked certificate, rendering the entire revocation infrastructure useless!
3. OCSP Stapling Economics & Performance:
   • CA Request Volume:
     • Without stapling: $25,000\text{ req/sec} \times 86,400\text{ sec/day} = \mathbf{2.16 \times 10^9\text{ queries/day}}$ to the CA.
     • With OCSP stapling: Each of the 10 edge servers refreshes its cached OCSP response once every 12 hours ($2\text{ queries/day/server}$).
     • Total daily requests to CA: $\text{Daily Queries} = 10 \times 2 = \mathbf{20\text{ queries/day}}$
     • Reduction in CA load: $\frac{2,160,000,000 - 20}{2,160,000,000} \approx \mathbf{99.999999\%}$.
   • Client Latency Overhead:
     • The stapled OCSP response is embedded directly within the TLS CertificateStatus message during the handshake.
     • Extra client round trips = $0$.
     • Additional client network latency overhead = $\mathbf{0\text{ ms}}$ (saving $140\text{ ms}$ on every cold connection while preserving 100% privacy).

---

🎯 Exam & Interview Pitfall Check

Question 1: Explain how an X.509 digital certificate solves the Man-in-the-Middle (MitM) problem in public key cryptography. Trace the verification process executed by a web browser.

Answer:

• How X.509 Solves the MitM Problem:
  • In unauthenticated public key exchange, an attacker can intercept communication and substitute their own public key, impersonating the target server.
  • An X.509 digital certificate prevents this by having a trusted third party—a Certificate Authority (CA)—cryptographically bind the server's identity (domain name example.com in the Subject Alternative Name field) to the server's authentic public key. The CA signs this binding using its own private signing key.
  • Because the attacker does not possess the CA's private signing key, the attacker cannot forge a valid digital certificate for example.com.
• Browser Verification Process:
  1. Validity Check: The browser verifies that the current system clock falls strictly within the certificate's Not Before and Not After validity timestamps.
  2. Domain Identity Matching: The browser verifies that the domain in the address bar matches a name listed in the certificate's Subject Alternative Name (SAN) extension.
  3. Signature Chain Verification: The browser hashes the certificate fields and decrypts the CA signature using the issuing Intermediate CA's public key. If the calculated hash matches the decrypted signature, the certificate is authentic.
  4. Chain Traversal to Root: The browser repeats this process recursively up the certificate chain until it reaches a self-signed Root CA present in its pre-installed Root Trust Store.
  5. Revocation Check: The browser verifies via OCSP Stapling that the certificate has not been revoked.

---

Question 2: Contrast the TLS 1.2 handshake with the TLS 1.3 handshake. Why did TLS 1.3 completely ban static RSA key exchange?

Answer:

• Comparison:
  • TLS 1.2 Handshake ($2 \times RTT$): Requires two full round trips before application data can be transmitted. In Round 1, the client and server negotiate ciphers (ClientHello, ServerHello). In Round 2, the server sends its certificate, the client sends its key exchange message (ClientKeyExchange), and both exchange Finished messages.
  • TLS 1.3 Handshake ($1 \times RTT$): The client preemptively generates its ephemeral Diffie-Hellman key share and includes it directly inside the initial ClientHello message. The server responds with its chosen cipher, its own key share (ServerHello), its certificate, and Finished. The client can immediately transmit encrypted application data on its second packet, saving an entire round trip ($1 \times RTT$).
• Why Static RSA Key Exchange Was Banned:
  • In static RSA key exchange, the client encrypts the pre-master secret using the server's long-term public key.
  • Fatal Flaw: It lacks Perfect Forward Secrecy (PFS). If an adversary captures and records encrypted network traffic today, and compromises or subpoenas the server's private RSA key years later, the adversary can decrypt all historical recorded communications.
  • TLS 1.3 mandates Ephemeral Diffie-Hellman (ECDHE) for all connections, ensuring that every session uses temporary keys that are discarded immediately, rendering retroactive decryption impossible.

---

Core Conceptual Questions

• What is Certificate Transparency (CT)?: Historically, rogue or compromised CAs issued fraudulent certificates for major domains without detection (e.g. DigiNotar in 2011). Certificate Transparency (RFC 6962) requires CAs to submit every newly issued certificate to public, append-only, cryptographically audited Merkle tree logs. Modern browsers reject certificates that lack proof of inclusion (Signed Certificate Timestamps - SCTs) in public CT logs.
• Can two different domain names share the same IP address under HTTPS?: Yes! Historically, TLS handshakes occurred before HTTP requests, so servers could not know which certificate to present. SNI (Server Name Indication - RFC 6066) introduced an extension in ClientHello where the browser declares the requested hostname, allowing a single IP address to host thousands of independent HTTPS domains.

Common Interview Traps

• Trap: Confusing Root CAs with Intermediate CAs: Root CAs are self-signed and live offline in high-security vaults. Day-to-day web certificates are issued exclusively by Intermediate CAs. If an issuance key is leaked, only the Intermediate CA is revoked, sparing the Root CA from compromise.
• Trap: Assuming HTTPS Encrypts the Domain Name in Transit: Standard TLS encrypts the HTTP path, headers, cookies, and payload body. However, the domain name itself is leaked in plaintext in the SNI header of the ClientHello message! Encrypting the SNI requires the emerging Encrypted Client Hello (ECH) standard.

---

🗺️View Complete Computer Networks Roadmap & Syllabus

← Previous Topic9.4 Cryptographic Hash Functions (SHA-256) & Digital SignaturesNext Topic →9.6 Firewalls (Packet Filtering, Stateful Inspection) & IDS/IPS