📜 07-08: Digital Certificates and PKI¶
📌 The Problem: Whose Public Key Is This, Really?¶
Every tool in this module so far has quietly assumed one thing: you already have the correct public key for the person you're talking to. RSA encryption (07-04: Asymmetric Encryption (RSA)) assumes you have the real recipient's public key. Digital signature verification (07-07: Digital Signatures) assumes you have the real sender's public key.
But how do you actually get that key in the first place — and how do you know it's genuine?
Imagine visiting your bank's website. Your browser needs the bank's public key to set up an encrypted connection. But the public key itself arrives over the same untrusted network an attacker might control (recall MITM attacks, 03-05: MITM Attacks & Defenses). What stops an attacker from simply handing you their own public key and claiming, "this is the bank's key"? If you accepted it, you'd encrypt your login credentials straight to the attacker, who could decrypt everything with their matching private key.
💥 This is the public key trust problem: possessing a public key proves nothing about who it actually belongs to. You need some way to bind a specific public key to a specific verified identity — and to do that in a way that scales to millions of websites and billions of users who've never met in person.
Digital certificates and PKI (Public Key Infrastructure) are the system built to solve exactly this.
📇 What's Inside a Digital Certificate¶
A digital certificate (the standard format is called X.509) is a small, signed document that binds a public key to an identity. Think of it like a notarized ID card for a public key.
| Field | Meaning | Example |
|---|---|---|
| Subject | Who/what this certificate identifies | www.yourbank.com |
| Public Key | The subject's public key | (n=..., e=...) — an RSA public key, or equivalent |
| Issuer | Who vouches for this certificate | DigiCert Global CA |
| Validity Period | When the certificate is trustworthy | Not Before: 2026-01-01, Not After: 2027-01-01 |
| Serial Number | Unique identifier for this specific certificate | 03:a1:9f:... |
| Signature | The issuer's digital signature over all the above fields | (a long cryptographic value) |
💡 The signature field is the whole point. The issuer (a Certificate Authority, or CA) uses its own private key to sign a hash of everything else in the certificate — subject, public key, validity dates, all of it — exactly the sign-the-hash process from 07-07: Digital Signatures. Anyone can then verify that signature using the CA's well-known public key, confirming the CA really did vouch for this exact subject-and-key combination, unaltered.
How Verification Actually Works¶
When your browser receives yourbank.com's certificate:
- It hashes the certificate's contents (subject, public key, dates, etc.).
- It uses the issuing CA's public key to check the certificate's signature against that hash.
- If the signature checks out, the browser trusts that the CA really did certify: "this public key belongs to yourbank.com."
- The browser also checks the validity dates and confirms the certificate hasn't been revoked.
If any of these checks fail — wrong signature, expired dates, revoked certificate, or subject name mismatch — the browser shows a warning instead of silently proceeding.
🔗 The Chain of Trust¶
There's an obvious follow-up question: how do you trust the CA's public key? You can't just take the certificate's word for it — that would let anyone self-certify. The answer is a chain of trust, typically three levels deep:
Root CA --signs--> Intermediate CA --signs--> Leaf (server) certificate
(deeply trusted, (delegated authority) (your bank's actual
kept offline) certificate)
| Level | Role | Example |
|---|---|---|
| Root CA | The ultimate trust anchor; its public key is pre-installed in your OS/browser | A small number of globally trusted root authorities |
| Intermediate CA | Certified by the root, does the actual day-to-day issuing | Issued and signed by a root CA |
| Leaf certificate | The certificate for an actual website/server | yourbank.com's certificate, signed by an intermediate CA |
Why Not Just One Level?¶
- Root CA keys are exceptionally sensitive — if a root key is ever stolen, an attacker could forge certificates for any domain on Earth, and every browser trusting that root would be fooled. Root CAs are kept offline in high-security facilities and used as rarely as possible.
- Intermediate CAs do the routine work of issuing everyday certificates. If an intermediate CA's key is ever compromised, only certificates issued through that intermediate need to be revoked and reissued — the root itself stays safe and doesn't need to be replaced (which would otherwise require updating every device on the planet).
💡 Your browser verifies the entire chain: it checks that the leaf certificate is validly signed by the intermediate, and that the intermediate is validly signed by a root CA it already trusts (from its built-in list). If every link in the chain checks out, the browser trusts the leaf certificate's public key belongs to the claimed website.
🏗️ PKI: The Bigger Picture¶
PKI (Public Key Infrastructure) is the umbrella term for the entire system of people, policies, hardware, and software that make certificates work at scale:
- Certificate Authorities (CAs) — organizations trusted to verify identities and issue certificates.
- Registration processes — how a CA confirms "you really do control
yourbank.com" before issuing a certificate for it (domain validation, organization validation, extended validation). - Certificate revocation — mechanisms (like CRLs — Certificate Revocation Lists — and OCSP — Online Certificate Status Protocol) to invalidate a certificate early, e.g., if a private key is stolen before the certificate's expiration date.
- Trust stores — the pre-installed lists of trusted root CA public keys that ship with every operating system and browser.
| Concept | Analogy |
|---|---|
| Root CA | A national government issuing the authority to notarize documents |
| Intermediate CA | A licensed notary public, authorized by the government |
| Leaf certificate | A specific notarized document (your bank's ID) |
| Trust store | The list of governments you personally recognize as legitimate |
| Revocation | The notary's license being pulled after they were caught issuing fraudulent notarizations |
💡 PKI doesn't just "encrypt things" — its entire purpose is answering a trust question: "whose public key is this, and can I believe that?" Every other cryptographic tool in this module (encryption, hashing, signatures) assumes you already have a trustworthy public key to work with. PKI is what actually gets you there.
🚀 Where This Goes Next¶
You now have every foundational building block this course needs before tackling real-world secure protocols:
| Concept | Lesson |
|---|---|
| Confidentiality via shared keys | 07-02: Symmetric Encryption Basics |
| Real symmetric cipher + modes | 07-03: AES & Block Cipher Modes |
| Confidentiality without pre-shared keys | 07-04: Asymmetric Encryption (RSA) |
| Deriving a shared key over an open channel | 07-05: Diffie-Hellman Key Exchange |
| Integrity | 07-06: Hashing & Message Integrity |
| Authenticity | 07-07: Digital Signatures |
| Trust in a public key's identity | This lesson |
💡 This is the foundation for Module 09: TLS/SSL. When your browser connects to an HTTPS website, it performs, in sequence: certificate verification (this lesson) to trust the server's identity, a Diffie-Hellman-style exchange to derive a shared session key, and then AES-GCM to encrypt the actual traffic — all backed by hashing and signatures to keep everything tamper-evident along the way. Module 08 (VPN/IPsec) reuses this same toolkit to secure traffic between entire networks instead of a single browser session.
📌 Key Takeaways¶
- Possessing a public key proves nothing about who it belongs to — digital certificates solve this by binding a public key to a verified identity.
- An X.509 certificate contains a subject, its public key, an issuer, a validity period, and a signature from the issuer over all of it.
- Certificate verification means checking the issuer's (CA's) signature against the certificate's contents — the same sign-the-hash process from digital signatures.
- The chain of trust runs Root CA → Intermediate CA → Leaf certificate; each link is verified by checking a signature against the next link up.
- Root CA keys are kept extremely secure and used rarely; intermediate CAs handle routine issuance so a compromise doesn't require replacing globally trusted root keys.
- PKI (Public Key Infrastructure) is the full ecosystem: CAs, identity verification processes, revocation mechanisms (CRLs, OCSP), and the trust stores built into every browser and OS.
- Revocation matters because a certificate can become untrustworthy before its expiration date (e.g., a stolen private key) — CRLs and OCSP let clients check for this.
- Certificates and PKI are the trust layer that makes every other tool in this module usable at internet scale — and they are the direct foundation for how TLS/SSL (Module 09) establishes secure, verified connections.