PKI Explained: Certificates Without Tears

By Taylor Thomas · 2026-08-30

Strip away the acronyms and a certificate is one sentence: this public key belongs to this name, signed by someone you may trust. Public key infrastructure is everything required to make that sentence checkable by machines at scale — the authorities that sign, the chains that connect signatures to anchors, the enrollment that gets keys certified, and the revocation that unsays a claim that went bad. Network security runs on it: 802.1X with EAP-TLS, certificate-authenticated IKEv2 tunnels, and certificate-based TLS inspection on your firewall all stand on the same machinery.

Trust Is Anchored Locally

The part that unlocks the rest: a certificate is not trusted because of anything it says. It is trusted because the verifier can validate a certification path from it to a trust anchor already configured in the verifier’s own trust store. In the common shape, the server’s certificate is signed by an intermediate CA and the intermediate’s certificate by a root — paths can be shorter or longer; the root is commonly a self-signed certificate sitting in the operating system, browser, or device trust store — shipped there, or installed by an administrator. Validation walks that chain checking signatures, validity dates, and the constraint extensions on the certificates in the path — the anchor itself is trusted out of band, by being in the store — and succeeds only if the path lands on a local anchor. This is why the same certificate can be valid to one client and untrusted to another — the difference is in their trust stores, not the certificate — and why enterprise PKI works at all: install your internal root CA certificate as a trust anchor across your devices and you become an anchor for your own estate.

Roots stay offline in sound practice. The day-to-day signing happens at intermediates, so a compromised or retiring issuer can be cut loose and replaced without disturbing the anchor certificate distributed to every trust store.

Enrollment: The Private Key Should Stay Home

Getting a certificate is the piece engineers touch most, and in the model to prefer the private key stays where it was made. The device generates a keypair, bundles the public key and its requested identifiers into a certificate signing request, and submits that; the request’s own signature proves possession of the private key. The CA authenticates the requester by whatever policy it enforces and decides what the issued certificate says. At fleet scale this is normally automated: SCEP and EST are two common enrollment protocols that let switches, routers, firewalls, and endpoints request and renew certificates automatically — the machinery underneath certificate-based EAP-TLS rollouts, where every endpoint needs its own certificate and renewal must not involve a human.

The certificate itself is a small bundle of constraints worth reading once in full: the subject and its alternative names, the validity window, and the constraint fields — basic constraints, key usage, extended key usage — that declare what the certificate may be used for. A properly profiled server certificate carries neither the CA flag nor certificate-signing usage, so a conforming validator will not accept it as an issuer — and that enforcement is what keeps the hierarchy a hierarchy. One validation detail earns its own sentence because it burns real deployments: standards-conforming TLS identity validation matches the server’s name against the Subject Alternative Name entries, with no fallback to the Common Name — and mainstream modern clients conform. A certificate missing the right SAN fails their name checks no matter what its CN says.

Revocation: The Hard Part

Issuing claims is easy; retracting them is not. A CA publishes revocations as a certificate revocation list — a signed, periodically refreshed file the client downloads — and can answer per-certificate queries over OCSP; many offer both. Both inherit a hard tradeoff: when revocation data is unreachable, a client without still-valid cached status must choose between failing closed on possibly healthy infrastructure and proceeding on a possibly revoked certificate. Much of the web client ecosystem historically proceeds; enterprise relying parties — the EAP-TLS and VPN endpoints a network engineer configures — are policy-driven and can fail closed. Engineering has responded from both ends — OCSP stapling removes the client’s dependence on reaching the responder by having the server deliver a recent status — signed by the CA or its delegated responder, fetched in advance — inside its own handshake (though a client that does not require a staple falls back to its normal policy), and ever-shorter certificate lifetimes shrink the window a compromised certificate stays valid — provided renewal rotates the key — trading revocation’s uncertainty for the certainty of expiry — a complement to revocation, not a substitute where policy requires status checking, and no help at all if renewal reuses a compromised key. The operational lesson: lean on lifetime and renewal automation where your relying parties support them, and fit the revocation machinery to the risk the certificate carries.

Where the Exam Meets the Machinery

PKI is named in the SCOR 350-701 cryptography objective, beside the TLS and IPsec that consume it — and IKEv2’s certificate authentication and your firewall’s TLS inspection are both this same chain-and-anchor logic wearing different uniforms. The algorithms inside certificates are also where the post-quantum migration will eventually land, so the chain-and-anchor concepts learned now will still be doing the work, even as certificate profiles and sizes change. For the guided version with real gear, the first lesson is free.

Frequently Asked Questions

What is the difference between a root CA and an intermediate CA?

A root CA is commonly represented by a self-signed certificate installed as a trust anchor; it is what a chain must validate up to. An intermediate CA holds a certificate issued by the root (or another intermediate) and does the routine signing. Keeping the root key offline and issuing through intermediates limits the damage of a compromise: an intermediate can be revoked and replaced without touching the anchor every trust store holds.

Why did my certificate fail with the name correct in the Common Name?

Because standards-conforming TLS validation — which mainstream modern clients follow — checks the name against the Subject Alternative Name extension, with no fallback to the Common Name. A certificate whose SAN list omits the name being connected to fails name validation even if the CN matches. When requesting a certificate, put every DNS name and, where relevant, IP address that clients will actually use into the SAN list.

Does the private key ever leave the device during enrollment?

Not in the model to prefer. The device generates its own keypair, wraps the public key and requested identifiers into a certificate signing request, and sends only that to the CA; what returns is a certificate — public information. Centralized key generation and PKCS#12 transport are legitimate where policy demands them (escrow, migration, appliances importing an inspection CA), but they move the protection burden onto the transport and storage of that key.