Public Key Infrastructure: Certificates, CAs and Revocation

Public key cryptography lets strangers communicate securely, but only if you can answer one question: does this public key really belong to who it claims? PKI is the infrastructure built to answer that question at scale, and nearly every part of it exists to support that single assurance.

What a Certificate Is

An X.509 certificate binds an identity to a public key, and a certificate authority signs that binding. The fields worth knowing:

  • Subject — who the certificate identifies.
  • Issuer — which CA signed it.
  • Public key — the key being vouched for.
  • Validity period — not-before and not-after dates.
  • Serial number — unique to the issuing CA, and what revocation lists reference.
  • Subject Alternative Name (SAN) — the additional names the certificate covers. Modern browsers validate against SAN, not the common name, so a certificate with the right CN and no matching SAN fails.
  • Key usage and extended key usage — what the key may be used for: server authentication, client authentication, code signing, email.
  • Signature — the CA's signature over all of the above.

The Chain of Trust

A root CA sits at the top with a self-signed certificate. Its private key is kept offline, frequently in a hardware security module in a vault, because compromise of a root invalidates everything beneath it.

Roots sign intermediate CAs, and intermediates sign end-entity certificates. The intermediate exists so the root can stay offline and so a compromised issuing CA can be revoked without replacing the root in every browser and operating system on earth.

Validation walks the chain from the presented certificate up to a root the client already trusts, checking each signature, each validity period and each revocation status. A server that fails to send its intermediate certificate produces the classic intermittent failure: it works in browsers that have cached the intermediate and fails everywhere else.

Getting a Certificate

The subject generates a key pair, keeps the private key, and submits a certificate signing request containing the public key and the identity details. The CA validates and issues.

Three validation levels: domain validation proves only control of the domain and is automated; organization validation checks the organization exists; extended validation applies the strictest checks, though browsers no longer display it distinctively, which has largely removed its commercial point.

Note what DV means in practice: an attacker who has taken over a domain can obtain a valid certificate for it within minutes. That is why registrar-level controls matter so much, as covered in domain hijacking, and why CAA records restricting which CAs may issue for your domain are worth setting.

Revocation

Certificates sometimes must be invalidated before expiry — a stolen private key, a decommissioned server, a misissued certificate.

CRL (Certificate Revocation List) is a signed list of revoked serial numbers published by the CA. It grows, it is fetched periodically, and it is therefore always somewhat out of date.

OCSP (Online Certificate Status Protocol) queries the CA about one certificate in real time. Fresher, but it adds latency and tells the CA which sites a user is visiting — a privacy problem.

OCSP stapling resolves both: the server periodically fetches a signed, timestamped status for its own certificate and staples it to the TLS handshake. No extra client request, no privacy leak.

The uncomfortable reality is that revocation checking is weakly enforced. Many clients fail open when the responder is unreachable, because failing closed would break browsing during any CA outage. Short certificate lifetimes have become the practical mitigation — a 90-day certificate limits exposure more reliably than revocation does.

Key Management

The private key is the whole game. It must be generated with good randomness, stored so that it cannot be extracted, and never transmitted. Hardware security modules exist for exactly this.

Key escrow stores a copy with a trusted third party so encrypted data can be recovered if the key is lost — valuable for encrypted files, dangerous for signing keys, since a copied signing key undermines non-repudiation. Related lifecycle practice is covered in key rotation.

Exam Focus

Know the CA signs, the root stays offline, and intermediates do the issuing. Know a CSR carries the public key and never the private one. Know SAN is what modern clients validate. Know CRL is a periodic list while OCSP is a real-time query, and stapling fixes OCSP's latency and privacy problems. Given an untrusted-certificate error on some clients only, suspect a missing intermediate. Symmetric keys agreed under this infrastructure then do the bulk work, as described in symmetric encryption.

Comments