PKI & Certificates · Good To Know

Diffie–Hellman gives you a shared secret with somebody; a certificate is how you learn who. PKI solves the binding problem — associating a public key with a name — by delegating the assertion to a third party the client already trusts. The construction is sound. The trust model it rests on is the part that has repeatedly failed in practice.

What a certificate is #

An X.509 certificate is a signed statement. Strip the ASN.1 and it says: this CA asserts that this public key belongs to these names, until this date, plus a signature over all of it.

Field	Purpose
Subject / SAN	the names bound to the key. Subject Alternative Name is authoritative — Common Name has been ignored by browsers since ~2017
Subject Public Key Info	the key itself, with its algorithm
Issuer	which CA signed this
Validity	not-before / not-after
Basic Constraints	`CA:TRUE/FALSE` and path length — whether this cert may sign others
Key Usage / EKU	what the key may do (signing, key agreement, `serverAuth`)
SCT list	Certificate Transparency proofs (below)

Verification walks the chain from leaf to a trust anchor in the client's root store, checking at every link: signature validity, dates, CA:TRUE on intermediates, path length, name constraints, EKU, and revocation. Then, separately, that the leaf's SAN actually matches the hostname the client asked for.

The weakest-link problem #

Any CA in the client's root store can issue a certificate for any name. A browser trusts on the order of 150 roots, operated across dozens of jurisdictions. The security of every HTTPS connection is therefore the minimum over all of them, not the maximum.

2008 A chosen-prefix MD5 collision forges a rogue CA certificate against RapidSSL using 200 PlayStation 3s.
2011 Comodo and then DigiNotar are breached; DigiNotar-issued certificates for *.google.com are used to intercept ~300,000 Iranian users. DigiNotar is removed from every root store and goes bankrupt.
2012 TrustWave admits issuing a subordinate CA for corporate TLS interception.
2015 CNNIC/MCS issues unauthorized Google certificates; CNNIC is distrusted.
2017 Symantec — then the largest CA — is found to have mis-issued thousands of certificates; browsers force a staged distrust and the business is sold.

Three mechanisms grew out of this history, and they fix different things.

Certificate Transparency #

Every publicly-trusted certificate must be logged to append-only, publicly-auditable Merkle-tree logs. The CA submits the certificate and receives a Signed Certificate Timestamp, embedded in the cert; browsers reject certificates without sufficient SCTs.

Monitoring your own domains in CT (crt.sh, or a commercial monitor) is cheap and catches both attacks and internal process failures.

Revocation, and why it barely works #

Mechanism	How	Reality
CRL	client downloads the CA's revocation list	lists grew to megabytes; largely abandoned
OCSP	client queries the CA per certificate	latency, privacy leak (the CA learns your browsing), and soft-fail
OCSP stapling	server attaches a fresh signed OCSP response	good, but optional; Must-Staple fixes that and is rarely deployed
Browser lists	CRLSets / OneCRL — curated, pushed with the browser	what actually works, but only covers high-profile revocations

Soft-fail makes online revocation checking near-useless

If the OCSP responder is unreachable, browsers proceed anyway — otherwise a CA outage would break the web. But an attacker positioned to use a stolen certificate is, by definition, positioned to block the OCSP query. Revocation checking that fails open does not stop the attacker it was designed to stop.

The industry's actual answer is short lifetimes. Maximum certificate validity has fallen from 5 years to 398 days to 47 days, with the CA/Browser Forum on a path to shorter still. A certificate that expires in weeks limits exposure without depending on revocation reaching the client — expiry is the one revocation mechanism that cannot be blocked. This is only tolerable because ACME automated issuance; the two changes are causally linked.

Pinning #

Pinning restricts which key or CA is acceptable for a specific host, collapsing the trust set from 150 CAs to one.

HPKP (HTTP header pinning) is dead — removed from browsers. It was too easy to brick a site permanently ("HPKP suicide"), and it enabled ransom attacks.
Application pinning is alive and correct for mobile apps and API clients, where you control both ends and can ship an update. Pin to an intermediate or to a key you control, always ship a backup pin, and have a rollout plan — a pin without a spare key is an outage waiting for a key rotation.
DANE/TLSA puts the binding in DNSSEC. Real in SMTP; browsers never adopted it.

Operating this in practice #

Automate with ACME. Let's Encrypt and RFC 8555 turned certificates from an annual manual purchase into a cron job. Given 47-day lifetimes, automation is not optional.
Validate the whole chain, including hostname. Use the platform's verifier. Never disable verification; if a development environment needs it, use a local CA added to the trust store instead.
Watch key usage and constraints. Name constraints on internal CAs limit blast radius; an unconstrained internal root in the OS trust store can impersonate the entire internet to that machine.
Monitor CT for your domains.
Prefer ECDSA P-256 or Ed25519 leaf keys — smaller chains, faster handshakes — subject to what your CA and clients support.