PKI: Public Key Infrastructure

What PKI is

PKI (Public Key Infrastructure) is the trust system that lets TLS, IPsec, and SSH certificates actually mean something: a framework of certificates, certificate authorities (CAs), and the rules for issuing and verifying them, standardized for the X.509 certificate format in RFC 5280. Every certificate-based check in the previous three lessons — a TLS server's identity, an IPsec gateway's certificate-based authentication, an SSH certificate replacing trust-on-first-use — ultimately depends on the same underlying PKI concepts this lesson covers: what a certificate contains, how trust is chained, and how a certificate can be invalidated before it expires.

X.509 certificates

An X.509 certificate binds a public key to an identity, signed by whoever issued it. The fields that matter most: the subject (who the certificate identifies — a hostname, for a TLS server), the issuer (the CA that signed it), the public key itself, a validity period (not-before and not-after dates), the Subject Alternative Name (SAN) extension (the actual list of hostnames a TLS certificate is valid for — the field clients check against, not the subject field alone), and the issuer's digital signature over everything else — the part that makes tampering detectable.

The chain of trust

Certificates don't stand alone — they form a chain of trust. A root CA sits at the top, is self-signed, and is pre-installed as trusted in an operating system's or browser's trust store. Rather than signing every end-entity certificate directly, a root CA signs one or more intermediate CA certificates, which then sign the actual leaf (end-entity) certificates servers present. This indirection exists specifically so the root CA's private key — the single most sensitive key in the entire system — can stay offline and rarely used, while intermediates handle day-to-day issuance and can be revoked and replaced individually if one is ever compromised, without having to distrust the root itself.

Certificate validation

Validating a certificate means walking this chain and checking it at every link: verifying the leaf's signature using the intermediate's public key, the intermediate's signature using the root's public key, and confirming that root is actually present in the client's trust store — plus checking the leaf's validity dates haven't expired and that the hostname being connected to actually appears in its SAN extension. This pre-installed trust store is precisely what lets PKI solve the problem SSH's trust-on-first-use leaves open: a client can trust a server it has never connected to before, because it already trusts the root the server's certificate chains up to — at the cost of placing a lot of trust in that fixed set of root CAs.

Interactive certificate chain validation

Step through a client validating a server's certificate: checking the leaf's signature against the intermediate, the intermediate's signature against the root, confirming the root is already trusted, and checking validity and hostname before the chain is accepted.

Certificate revocation

A certificate's validity period alone isn't enough — a private key can be stolen long before its certificate expires, and that certificate needs to stop being trusted immediately, not months later. CRLs (Certificate Revocation Lists) are periodically published lists of revoked certificate serial numbers a client can download and check. OCSP (Online Certificate Status Protocol) instead lets a client query a CA in real time for one certificate's current status. OCSP stapling improves on plain OCSP by having the server periodically fetch its own signed OCSP response and attach ("staple") it to the handshake — the client gets the same proof without a separate round trip to the CA for every connection, and without revealing to the CA which sites a particular client is visiting.

Inspect PKI evidence

openssl x509 -in cert.pem -text -noout prints every field of a certificate in human-readable form — subject, issuer, validity dates, SAN entries, and the signature algorithm. openssl s_client -connect host:443 -showcerts dumps the entire chain a server actually presents, which is the fastest way to confirm whether a missing intermediate is the problem. openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem manually walks and verifies a chain against a specific trusted root, which is useful for testing a chain independently of any particular browser's trust store.

Guided chain-of-trust practice

Work through what actually happens if an intermediate CA's private key is compromised, and why the root doesn't need to be replaced as a result. The root CA's key itself was never exposed, so the root remains trustworthy — but every certificate that compromised intermediate ever issued is now suspect, because an attacker holding that key could have issued fraudulent certificates for any hostname. The fix is to revoke that one intermediate (added to a CRL, or simply removed from distribution) and have all genuinely legitimate certificates it issued re-issued under a new, uncompromised intermediate. This is exactly the isolation intermediates are designed to provide: a compromise is contained to what that one intermediate touched, rather than invalidating the entire chain of trust back to the root.

Troubleshoot PKI

1. Check for a missing intermediate certificate first: a server that only serves its leaf certificate forces every client to already have the correct intermediate cached, which many don't — this is the single most common cause of "untrusted certificate" errors on a certificate that was actually issued correctly.
2. Confirm the certificate's actual not-after date rather than assuming it hasn't expired — an expired certificate produces the same category of browser warning as an untrusted chain, but the fix is entirely different (renewal, not a missing intermediate).
3. Check the SAN extension against the exact hostname being requested — a certificate can be perfectly valid and trusted and still fail for the wrong hostname, such as a certificate issued for www.example.com being presented for example.com without both names listed.
4. Distinguish a genuinely self-signed, untrusted certificate (no path to any trusted root at all) from a broken chain (a path exists but an intermediate is missing) — the first requires explicitly trusting that certificate, the second just requires the server to send its full chain.
5. Rule out client clock skew: certificate validity checks compare absolute timestamps, so a sufficiently wrong client clock can reject a perfectly valid certificate (or fail to reject an actually-expired one).
6. Remember that revocation checks commonly soft-fail: if a client can't reach an OCSP responder, many implementations proceed as though the certificate were valid rather than blocking the connection — a known trust gap, not a malfunction.

Knowledge check and summary

Pro deep dive