Example 1: HTTPS Connection — Full Trust Chain Verification
You navigate to https://www.bank.com. Here is what happens in the milliseconds before the page loads:
- Server sends its certificate: Subject = www.bank.com, Issuer = "DigiCert TLS RSA SHA256 2020 CA1", Public Key = [RSA 2048-bit key].
- Server also sends the Intermediate CA's certificate: Subject = "DigiCert TLS RSA SHA256 2020 CA1", Issuer = "DigiCert Global Root CA."
- Browser checks: Is "DigiCert Global Root CA" in my trusted root store? YES.
- Browser verifies: Is the Intermediate CA's certificate signed by "DigiCert Global Root CA"? Computes hash of Intermediate cert fields, decrypts Root CA's signature using Root CA's public key (from trusted store), compares — MATCH.
- Browser verifies: Is www.bank.com's certificate signed by the Intermediate CA? Same process — MATCH.
- Browser checks: Does the SAN in the certificate include www.bank.com? YES.
- Browser checks: Is the certificate within its validity period? YES.
- Browser checks: Is the certificate revoked? (CRL/OCSP/Stapling) — NOT REVOKED.
- All checks pass → padlock appears → TLS handshake proceeds.
Example 2: Internal Private CA
A company wants TLS for all internal systems (HR portal, admin console, dev environments) without paying for a public CA certificate for each one. They deploy an internal CA using Windows Certificate Services or a similar PKI solution.
The internal Root CA certificate is pushed to all company devices via Group Policy — it is added to the OS trusted root store on all company machines. Now any certificate issued by this internal CA is automatically trusted by all company devices.
The company's admin can issue certificates for internal.company.com, hr.internal, dev-db01, etc. — without any external CA involvement or cost. External users see an "untrusted certificate" warning for these internal names (their browsers don't have the private CA in their trust store), which is acceptable since these systems are not meant for public access.
Example 3: Heartbleed — Certificates Don't Expire, They Must Be Revoked
When Heartbleed was disclosed in April 2014, the scenario was: an attacker can read 64KB of memory from any vulnerable OpenSSL server. That memory could contain the server's TLS private key.
If an attacker captured a server's private key, they could: impersonate that server forever (the certificate is still valid and the key pair matches), or decrypt past TLS sessions if they had recorded the traffic (depending on cipher suite — perfect forward secrecy would have limited this).
The mandatory response was: patch OpenSSL → THEN revoke all existing certificates (assuming private keys may have been stolen) → generate new key pairs → request new certificates → install new certificates. Skipping the revocation step would leave the old certificates (and potentially the stolen private keys) valid until natural expiration.
This incident overwhelmed CRL and OCSP infrastructure worldwide — millions of certificates being revoked and checked simultaneously. It demonstrated both the importance of revocation and the limitations of existing revocation infrastructure at scale.
Example 4: Wildcard vs. SAN — When Each is Appropriate
Use wildcard *.example.com when: You have many subdomains (www, api, mobile, static, cdn, mail, ftp...) all under one domain. One certificate covers them all. Simple to manage. Acceptable risk: if the wildcard cert's private key is stolen, all subdomains are affected simultaneously.
Use SAN certificate when: You need to cover multiple different domains (example.com AND example.net AND app.example.io) — wildcard cannot cover different top-level domains. Or you need sub-sub-domains (staging.api.example.com) — wildcard only covers one level. Or you want to minimize blast radius by not putting all subdomains on one certificate.
Exam Scenario 1
Question: A company's web server private key was stolen in a breach. The certificate is still valid for 8 more months. What should they do to prevent an attacker from using the stolen key to impersonate the server?
Answer: Immediately revoke the certificate with the issuing CA, then generate a new key pair and request a new certificate. Revocation informs browsers (via CRL/OCSP) that the old certificate should not be trusted even though it hasn't expired. Without revocation, an attacker holding the stolen private key could set up an impersonation server that passes TLS verification for 8 more months.
Exam Scenario 2
Question: What is the advantage of OCSP Stapling over standard OCSP?
Answer: Three advantages: (1) No added latency — the OCSP response is already in the TLS handshake, so no separate round-trip to the CA is needed. (2) Privacy — the CA never sees which specific certificate the user is checking (the server fetches the staple, not the user's browser). (3) Availability — if the CA's OCSP responder is temporarily offline, the stapled response (valid for 24-48 hours) still works; clients without stapling would fail-open (accept the cert anyway) or fail-closed (reject it), depending on browser behavior.