Public-Key Infrastructure and Certificates
Imagine downloading a browser update, or connecting to your bank's website. How does either endpoint know the other's public key actually belongs to who it claims? Digital Signatures let you verify a message came from a private key. But they say nothing about whose key it is. Public-Key Infrastructure (PKI) solves this binding problem. It is the system of authorities, formats, and protocols that lets a stranger's public key arrive with a credible, checkable claim of identity attached. This matters because almost every secure channel on the internet begins with a certificate. TLS, code signing, email encryption (S/MIME), and even Wi-Fi enterprise authentication (EAP-TLS) all lean on the same core object. That object is an X.509 certificate issued by a Certificate Authority (CA) and chained back to a root that your device already trusts. Without PKI, public-key cryptography is a beautiful hammer with no reliable way to find the right nail. Anyone could hand you a public key and claim it belongs to your bank. The big picture is a chain of vouching. A root CA, whose key is baked into your operating system or browser, vouches for intermediate CAs. Those intermediate CAs vouch for the certificates issued to actual websites and organizations. Each vouch is a digital signature over a structured document containing an identity and a public key. Verifying a certificate means walking this chain, and checking each signature. It also means checking validity periods, and checking that nothing has been revoked. This article builds the concept from the ground up. It covers what a certificate actually contains, and how chains are built and verified. It also covers the competing trust models (hierarchical CAs vs. the web of trust). Finally, it explores the surprisingly hard problem of revocation — telling the world a certificate should no longer be trusted, quickly, without breaking the internet. It sets up the machinery used directly in The TLS Handshake and in broader Key Management practice.
- PKI binds public keys to identities via signed documents called certificates, solving the "whose key is this?" problem left open by raw digital signatures.
- X.509 certificates carry a subject, issuer, public key, validity period, and extensions, all covered by the issuer's signature.
- Trust is established by chaining: leaf certificate → intermediate CA(s) → root CA, verified up to a pre-installed trust anchor.
- Two trust models exist: hierarchical CAs (used by the web) and decentralized webs of trust (used by PGP); each has different failure modes.
- Revocation (CRLs, OCSP, OCSP stapling, short-lived certs) is the hardest operational problem in PKI — "un-trusting" something that was already trusted.
- PKI failures (mis-issuance, compromised CAs, stale revocation checks) have caused real, large-scale internet security incidents.
A certificate is a signed statement — "this public key belongs to this identity" — and PKI is the entire system for issuing, chaining, verifying, and revoking those statements.
The idea
A digital certificate is a data structure that binds a subject (a name — a person, organization, or domain) to a public key, and is digitally signed by an issuer whose own identity is presumed (or separately) trustworthy. The dominant format is X.509, standardized by the ITU-T and profiled for the internet in RFC 5280. A certificate is not itself proof of anything beyond "the issuer signed this statement" — its value depends entirely on how much you trust the issuer and how carefully the issuer verified the subject's identity before signing. A Certificate Authority (CA) is an entity trusted to perform that verification and issuing. Because verifying every possible subject directly does not scale, CAs are arranged in chains of trust: a small number of root CAs have their public keys distributed out-of-band (shipped inside operating systems, browsers, and devices) as trust anchors. Roots sign certificates for intermediate CAs, which sign certificates for end-entity (leaf) certificates — the ones actually presented by websites and services. Verifying a certificate means validating a certification path from a leaf up to a trusted root, checking signatures, validity dates, name constraints, and key usage at every link. Two distinct trust architectures exist for this binding problem. The hierarchical (CA-based) model, used by The TLS Handshake and the web PKI, relies on a small set of globally trusted roots and strict path validation rules — trust flows top-down and is largely centralized. The web of trust model, used historically by PGP/GPG, instead lets any user sign any other user's key, and trust is computed peer-to-peer, often with a threshold ("I trust this key if at least k people I trust have signed it"). The hierarchical model scales better for anonymous strangers (like a random website); the web of trust degrades more gracefully against a single point of failure but scales poorly for people who don't already know each other.
How it works
1. What is inside an X.509 certificate
An X.509v3 certificate is, conceptually, three parts: the body (`tbsCertificate`, "to be signed"), the signature algorithm identifier, and the signature itself. ``` Certificate ::= tbsCertificate: version (e.g., v3) serialNumber (unique per issuer) signatureAlgorithm (e.g., ECDSA-with-SHA256) issuer (Distinguished Name of CA) validity (notBefore, notAfter) subject (Distinguished Name of holder) subjectPublicKeyInfo (algorithm + public key bytes) extensions: basicConstraints (isCA? path length limit?) keyUsage (digitalSignature, keyEncipherment, ...) extendedKeyUsage (serverAuth, clientAuth, codeSigning, ...) subjectAltName (DNS names, IPs — what browsers actually check) authorityKeyId (links to issuer's key, for chain building) subjectKeyId crlDistributionPoints authorityInfoAccess (OCSP responder URL, issuer cert URL) signatureAlgorithm (repeated, must match tbsCertificate's) signatureValue (issuer's signature over DER(tbsCertificate)) ``` The issuer computes `signatureValue = Sign(CA_private_key, Hash(DER-encode(tbsCertificate)))`. Anyone holding the CA's public key can verify this signature exactly as in ordinary Digital Signatures verification — the only new idea is that the object being signed is itself an identity/key binding, and the verifier of the CA's key is, recursively, another certificate or a hard-coded trust anchor.
2. Building and verifying a certification path
A chain (certification path) is a sequence of certificates `C_0, C_1, ..., C_n` where `C_0` is the leaf, `C_n` is issued by a trusted root, and each `C_i` is signed by the private key corresponding to the public key in `C_{i+1}`. ``` PSEUDOCODE: Certificate chain validation (simplified RFC 5280 path validation) function VERIFY_CHAIN(leaf, presented_chain, trust_store, current_time, hostname): chain = ORDER_CHAIN(leaf, presented_chain) # leaf, intermediate(s), (root) if chain is empty: return REJECT("no chain")
# Step 1: find a trust anchor root = FIND_ANCHOR(chain[-1], trust_store) if root is null: return REJECT("untrusted root") chain.append(root) # ensure root is included
# Step 2: walk the chain from root down to leaf for i from len(chain)-1 down to 1: issuer_cert = chain[i] subject_cert = chain[i-1]
# (a) signature check if not VERIFY_SIGNATURE(subject_cert.tbsCertificate, subject_cert.signatureValue, issuer_cert.subjectPublicKey): return REJECT("bad signature at depth " + i)
# (b) validity period if current_time < subject_cert.notBefore or current_time > subject_cert.notAfter: return REJECT("expired/not-yet-valid cert")
# (c) issuer must be marked as a CA (except for the leaf's issuer check target) if subject_cert is not leaf: if not issuer_cert.basicConstraints.isCA: return REJECT("issuer not a CA")
# (d) path length constraint if issuer_cert.basicConstraints.pathLenConstraint is set: if REMAINING_INTERMEDIATES(chain, i) > issuer_cert.basicConstraints.pathLenConstraint: return REJECT("path too long")
# (e) name constraints (if issuer restricts subject namespaces) if not SATISFIES_NAME_CONSTRAINTS(issuer_cert, subject_cert): return REJECT("name constraint violation")
# (f) key usage: must permit certificate signing for CAs if subject_cert is not leaf: if "keyCertSign" not in issuer_cert.keyUsage: return REJECT("issuer key not permitted to sign certs")
# (g) revocation check if IS_REVOKED(subject_cert, issuer_cert): return REJECT("certificate revoked")
# Step 3: leaf-specific checks if hostname not in leaf.subjectAltName: return REJECT("hostname mismatch") if "digitalSignature" not in leaf.keyUsage and "keyEncipherment" not in leaf.keyUsage: return REJECT("leaf key usage insufficient") return ACCEPT(chain) ``` ``` PSEUDOCODE: Revocation check (OCSP-style, with stapling fallback to CRL) function IS_REVOKED(cert, issuer_cert): if cert.has_stapled_ocsp_response: resp = cert.stapled_ocsp_response if VERIFY_SIGNATURE(resp.body, resp.signature, issuer_ocsp_signing_key) and resp.thisUpdate <= now <= resp.nextUpdate: return resp.status == REVOKED
# stapled response invalid/expired -> fall through if ONLINE_OCSP_AVAILABLE(cert.authorityInfoAccess.ocspURL): resp = QUERY_OCSP(cert.serialNumber, issuer_cert) if resp.verified and not resp.expired: return resp.status == REVOKED
# last resort: cached/fetched CRL crl = FETCH_OR_CACHE_CRL(cert.crlDistributionPoints) if crl.verified and not crl.expired: return cert.serialNumber in crl.revoked_serials
# soft-fail (common in browsers) vs hard-fail (higher assurance policies) return POLICY_DEFAULT_ON_UNKNOWN # soft-fail: NOT_REVOKED; hard-fail: REVOKED ```
3. The two trust models
Hierarchical (CA-based). A small, curated set of root CAs is embedded in each operating system's or browser's trust store (Microsoft, Apple, Mozilla, Google each maintain their own root programs with audit requirements — WebTrust/ETSI). Any leaf certificate is trusted if and only if it chains to some root in the local trust store. This scales beautifully for strangers: your browser can validate `example.com` with zero prior interaction with that site, because it already trusts the CA. The weakness is systemic: any root or intermediate CA compromise can be used to mint a certificate for any domain, and there are hundreds of trusted roots across the ecosystem.
Web of trust. Used by PGP/GPG for email and file signing. There is no privileged root; individuals sign each other's public keys after verifying identity (classically at "key-signing parties"), and each user assigns personal trust levels to signers. A key is accepted if it is directly signed by someone you trust, or transitively via a trust threshold. This avoids single points of institutional failure but requires an actual social network of verification, so it scales poorly to anonymous e-commerce — you cannot bootstrap trust in a bank you've never interacted with using peer attestations alone.
Complexity & correctness
Chain validation time. For a chain of length `n` (typically 2–4: root, 0–2 intermediates, leaf), validation performs `O(n)` signature verifications, each costing the underlying signature scheme's verify time (e.g., `O(1)` modular exponentiations for RSA, or `O(1)` elliptic-curve operations for ECDSA — both effectively constant-time per call, independent of the number of certificates in the ecosystem). Total path validation is `O(n)` cryptographic operations plus `O(n)` simple date/field comparisons, so overall `Θ(n)` time, dominated in practice by network round trips for fetching intermediates/CRLs/OCSP responses, not by the arithmetic.
Chain construction. If the server does not present a complete chain, the client may need to search for the correct intermediate among a candidate set (using `authorityKeyIdentifier` / `subjectKeyIdentifier` to match issuer to subject). In the worst case with `m` candidate certificates and a chain of depth `n`, naive search is `O(n · m)`, but indexing certificates by subject key identifier reduces lookup to `O(1)` per hop via a hash map, giving `O(n)` overall — this is why real implementations maintain local certificate stores indexed by key identifiers rather than by name.
Revocation checking cost. CRLs can be large (thousands to millions of serials for a busy CA); downloading and parsing a full CRL is `O(r)` in the number of revoked certificates, though delta CRLs and CRL partitioning reduce this. OCSP is `O(1)` per query (a single serial number lookup against a CA's database) but adds a network round trip per certificate checked, and per-visited-site latency became the reason browsers introduced OCSP stapling: the server, not the client, periodically fetches a signed, time-stamped OCSP response and attaches ("staples") it to the TLS handshake, turning an `O(chain length)` set of client-to-CA round trips into zero extra round trips.
Correctness argument (why chain validation is sound). The invariant maintained at each step of `VERIFY_CHAIN` is: > After processing link `i`, the subject of `chain[i-1]` is genuinely bound to its stated public key, assuming the issuer's key in `chain[i]` is genuine and the issuer followed its stated policy. The base case is the trust anchor: the root's public key is assumed genuine because it was installed through an out-of-band, non-cryptographic process (shipped in an OS image, verified by the OS vendor's own supply chain). The inductive step is exactly a Digital Signatures verification: if the signature scheme is existentially unforgeable under chosen-message attack (EUF-CMA secure), then no adversary lacking the CA's private key can produce a valid `signatureValue` over a `tbsCertificate` binding a different key or subject, except with negligible probability. So each successfully verified link transfers trust from issuer to subject with cryptographic (not just procedural) assurance — the only place actual human/policy trust enters is the CA's own vetting process before signing, which cryptography cannot verify and can only be audited externally.
Honest tradeoffs. PKI's soundness is contingent on: (1) CA private keys never leaking, (2) CAs actually verifying identity before issuing (domain validation, organization validation, extended validation differ wildly in rigor), (3) revocation information reaching relying parties before damage is done, and (4) trust stores being curated correctly. All four have failed in practice. The system is only as strong as its weakest trusted root, which is why modern practice adds Certificate Transparency (public, append-only logs of all issued certificates) as a detection layer on top of the prevention layer described above.
Worked example
Consider a browser connecting to `https://shop.example.com` and receiving this (simplified) chain during the TLS handshake:
| Field | Leaf (`shop.example.com`) | Intermediate (`ExampleCorp CA`) | Root (`GlobalTrust Root`) |
|---|---|---|---|
| Subject | CN=shop.example.com | CN=ExampleCorp CA | CN=GlobalTrust Root |
| Issuer | CN=ExampleCorp CA | CN=GlobalTrust Root | CN=GlobalTrust Root (self) |
| Serial | 7A3F91 | 11020304 | 01 |
| notBefore / notAfter | 2024-01-10 / 2025-01-10 | 2020-05-01 / 2030-05-01 | 2015-01-01 / 2040-01-01 |
| basicConstraints | CA=false | CA=true, pathLen=0 | CA=true |
| keyUsage | digitalSignature, keyEncipherment | keyCertSign, cRLSign | keyCertSign, cRLSign |
| subjectAltName | DNS:shop.example.com | — | — |
| Signed by | ExampleCorp CA's private key | GlobalTrust Root's private key | (self-signed, ignored in trust decision) |
Trace of `VERIFY_CHAIN` on 2024-06-15, requesting hostname `shop.example.com`: 1. Order chain: `[leaf, intermediate]` presented by server; client appends root found by matching `issuer` field to a trust-store entry named `GlobalTrust Root`. Root found → not rejected. 2. i = 2 (root, self-referential — skipped for signature check, used only as anchor). 3. i = 1, subject = intermediate, issuer = root:
- Signature: verify intermediate's `tbsCertificate` against root's public key using ECDSA-verify → succeeds (issuer genuinely signed it).
- Validity: `2020-05-01 ≤ 2024-06-15 ≤ 2030-05-01` → OK.
- `basicConstraints.isCA` on root → true → OK.
- `pathLenConstraint`: root has none set (unconstrained) → OK.
- Key usage: root has `keyCertSign` → OK.
- Revocation: OCSP-staple present for intermediate, signed and unexpired, status GOOD → not revoked.
4. i = 0, subject = leaf, issuer = intermediate:
- Signature: verify leaf's `tbsCertificate` against intermediate's public key → succeeds.
- Validity: `2024-01-10 ≤ 2024-06-15 ≤ 2025-01-10` → OK.
- Intermediate `isCA = true`, `pathLenConstraint = 0` and there are zero further intermediates below it → OK (0 remaining CAs beneath, satisfies constraint).
- Key usage: intermediate has `keyCertSign` → OK.
- Revocation: stapled OCSP for leaf, GOOD, unexpired → not revoked.
5. Leaf-specific checks: `shop.example.com ∈ subjectAltName` → match. `keyUsage` contains `digitalSignature` → sufficient for the TLS key exchange in use. 6. Result: ACCEPT. The browser now proceeds to use the leaf's public key in the The TLS Handshake key exchange, having cryptographically established that some entity vetted by GlobalTrust's chain asserts this key belongs to `shop.example.com`. Now perturb one field: suppose the intermediate's certificate had `pathLenConstraint = 0` but the leaf's `basicConstraints` had incorrectly been set to `CA=true` (a misconfiguration). Step 4's path-length check would still pass numerically (zero further CAs below the leaf), but a stricter validator enforcing "an intermediate with pathLen=0 must issue only non-CA leaves" would reject this as policy-inconsistent — illustrating why real validators implement additional consistency checks beyond the bare RFC 5280 arithmetic.
Common pitfalls & traps
| Pitfall | Why it happens | Consequence |
|---|---|---|
| Checking only the leaf's signature, not the whole chain | Naive implementations "verify the certificate" and stop | Any self-signed or expired-intermediate cert appears valid |
| Confusing Common Name (CN) with Subject Alternative Name (SAN) | Legacy code checked `CN` for hostname | Modern browsers ignore CN; mismatched hostnames slip through in custom TLS clients |
| Soft-fail revocation checking treated as "secure" | OCSP/CRL fetch failures default to "not revoked" for availability | An active attacker can simply block the revocation check to use a revoked cert |
| Ignoring `basicConstraints.CA` on intermediates | Assuming any signature from any cert in the chain suffices | A leaf certificate could sign another certificate, forging a "sub-CA" |
| Not validating the full validity-period chain (only checking leaf dates) | Devs assume intermediate/root dates "don't matter" | Chains through an expired intermediate wrongly accepted |
| Clock skew ignored | Assuming client clock is always correct | Valid certs rejected as "not yet valid" or expired certs wrongly accepted on a skewed clock |
| Trusting Certificate Transparency logs as sole gatekeeper | CT is a detection, not prevention mechanism | Mis-issued certs can still be used before anyone reviews the log |
Pioneers & history
The mathematics of binding identity to keys traces to the same lineage as Digital Signatures, but PKI as an institutional system was formalized through standards bodies and shaped by early public-key cryptography researchers who recognized that a signature alone does not solve the key-distribution problem.
Origins · 1 minLoren M. Kohnfelder and how this was discovered
As an MIT undergraduate, Loren Kohnfelder wrote the 1978 thesis that first proposed certificates and a certificate hierarchy as the practical mechanism for distributing public keys at scale — directly extending the key-distribution gap left open by Diffie–Hellman and RSA. His construction — a CA signing a binding of name to key — is, in essence, the X.509 model used across the modern internet.
Where this matters
PKI is the load-bearing wall underneath The TLS Handshake: every HTTPS connection begins with exactly the chain-validation process described above before any encrypted application data flows. Beyond the web, PKI underlies code signing (verifying that an OS update or app really came from its vendor), S/MIME and PGP email, EAP-TLS Wi-Fi authentication in enterprise networks, smart cards and government ID systems, IoT device provisioning (factory-embedded per-device certificates), and DNSSEC-adjacent trust chains. Cloud providers, certificate authorities like Let's Encrypt, DigiCert, and enterprise internal CAs (used for VPNs and internal service mesh mTLS) all implement the same certificate lifecycle: issue, distribute, validate, renew, and — critically — revoke. Understanding PKI is a direct prerequisite for reasoning about broader Key Management practices, since key rotation, hardware security modules, and escrow policies all exist to protect the CA private keys that anchor this entire trust structure.
Ask the tutor: How does certificate chain validation get embedded inside the actual TLS handshake message flow?
Why can't a digital signature alone solve the identity-binding problem?
A digital signature proves that a message was produced using a specific private key — it says nothing about who controls that key. If you receive a public key claiming to belong to your bank, a signature from that key only proves consistency with itself, not ownership. You need an independent, trusted third party to vouch for the binding between key and identity; that is exactly the role a Certificate Authority plays. PKI adds this missing layer: a CA verifies the claimant's identity through some out-of-band process (domain control, organizational documents, in-person verification) and then signs a certificate binding key to identity, giving relying parties a chain of accountability rather than a bare cryptographic artifact.
What is the difference between domain validation (DV), organization validation (OV), and extended validation (EV) certificates?
These represent increasing levels of identity vetting rigor by the CA before issuance, not stronger cryptography — the keys and signatures are identical in strength. DV certificates only confirm the requester controls the domain (e.g., via a DNS or HTTP challenge), which is why services like Let's Encrypt can issue them automatically in seconds. OV certificates additionally verify the requesting organization's legal existence through business registries. EV certificates require the most thorough vetting, historically displayed with a green address-bar indicator (since removed by most browsers due to limited user comprehension and phishing using EV certs from legitimately registered shell companies). All three provide identical transport encryption; they differ only in what identity claim you can trust.
Why do certificates expire instead of being valid forever?
Expiration bounds the damage from an undetected key compromise or mis-issuance and forces periodic re-verification of the subject's identity and continued control of the domain or key. It also enables cryptographic agility — as algorithms weaken or key sizes need to grow, expiration forces gradual migration rather than an indefinite legacy tail. Modern practice has pushed lifetimes shorter over time (from years down toward 90 days or less for public web certificates), partly because short lifetimes reduce reliance on revocation infrastructure: if a certificate naturally expires soon anyway, the urgency and blast radius of "we forgot to revoke it" shrinks substantially.
What is Certificate Transparency and how does it relate to PKI trust?
Certificate Transparency (CT) is a system of public, append-only, cryptographically verifiable logs that record every certificate issued by participating CAs. It does not prevent mis-issuance the way path validation does — instead, it makes mis-issuance detectable: domain owners and researchers can monitor logs for certificates issued for their domains without authorization. Modern browsers require CT log inclusion (via signed certificate timestamps) for public certificates to be trusted at all, turning CT from an optional audit tool into a mandatory second layer of accountability layered on top of traditional hierarchical PKI trust.
Can a certificate be valid but still not trustworthy?
Yes — validity (correct signature, unexpired, unrevoked, chains to a trust anchor) is necessary but not sufficient for trustworthiness. A DV certificate can be issued to a phishing domain that merely resembles a bank's real name (`bankofexarnple.com`), passing every technical check while still being malicious, because domain validation only confirms control of that specific domain string, not the legitimacy of the entity behind it. PKI answers "is this key bound to this claimed identity, according to the issuer's policy?" — it does not and cannot answer "should I trust this identity's intentions?", which is a separate, often human, judgment layered on top.
How does PKI degrade if a root CA's private key is compromised?
Catastrophically, and this is the system's known single point of failure: an attacker with a root's private key can mint valid certificates for any domain or identity, and every certificate chaining to that root would pass standard validation. Mitigations include: rapid distrust and removal of the compromised root from browser/OS trust stores (as happened with DigiNotar in 2011), Certificate Transparency monitoring to detect fraudulent issuance, hardware security modules (HSMs) to make root key extraction extremely difficult, and offline root CAs (kept powered off and air-gapped, used only rarely to sign intermediates) so that day-to-day issuance risk is confined to intermediates, which are easier to revoke and rotate than a globally embedded root.
Why is revocation considered harder than issuance in PKI?
Issuance is a single, synchronous event: the CA signs once, and the signature is permanently verifiable offline. Revocation, by contrast, is a claim about the absence of continued trust that must be actively and continuously communicated to every relying party, potentially for years after issuance, and checked at every use. This requires either a live query (OCSP, with availability and privacy costs — the CA can see connection patterns) or a periodically-refreshed list (CRLs, which grow unboundedly and go stale between refreshes). Every solution trades off latency, availability, privacy, and staleness, and none matches the simplicity of a single offline-verifiable signature — which is why short-lived certificates are an increasingly popular way to sidestep the problem rather than solve it.