PKI Structure: Root CAs, Intermediates, and What a CA Compromise Means

A certificate is only meaningful because something you already trust vouches for it. Public key infrastructure is the arrangement of who vouches for whom, and its structure is designed around one assumption: that a signing key will eventually be compromised, and the damage must be survivable.

Why roots sign intermediates rather than end entities

A root certificate authority's private key is the anchor of trust for everything beneath it, and its public certificate is embedded in operating systems and browsers. It cannot be revoked in any practical sense — revoking it means every device with it in its trust store must be updated, which for a widely distributed root is effectively impossible.

So the root key is kept offline, in hardware, under multi-person control, brought out rarely and ceremonially. It signs a small number of intermediate certificates and nothing else.

Intermediates do the day-to-day issuing. They are online, they are exposed, and — crucially — they can be revoked. Compromise of an intermediate is contained: revoke it, the root signs a replacement, and the trust anchor is untouched.

That is the entire reason for the hierarchy. It is not bureaucracy; it is designed compromise recovery, and the same logic applies to an internal PKI, where an offline root and online issuing CAs is the standard build.

Chain validation

A client presented with a certificate walks the chain upward: verify the signature on the end-entity certificate using the intermediate's public key, verify the intermediate's signature using the next certificate up, and continue until reaching a certificate in the local trust store.

At each step it also checks validity dates, that the name matches what was requested, that the key usage and extended key usage permit the purpose, that basic constraints allow a CA certificate to sign others, and revocation status.

Two practical failure modes dominate. A server that does not send the intermediate certificates leaves clients unable to build the chain — and it frequently works in a browser that cached the intermediate earlier while failing everywhere else, which makes it maddening to diagnose. And an expired intermediate breaks everything beneath it regardless of the end-entity certificate's dates.

Revocation, and why it underdelivers

Two mechanisms, covered in more depth under certificate lifecycle.

CRLs are signed lists of revoked serial numbers, published periodically. Simple, and they grow large and are only as current as the publication interval.

OCSP queries status for one certificate in real time. Current, and it adds a dependency and a privacy leak, since the responder learns which sites a client visits. OCSP stapling fixes both by having the server present a recent signed status itself.

The uncomfortable reality is that most clients fail open: if revocation status cannot be obtained, they proceed. Failing closed would break browsing whenever a responder has an outage, so the check is advisory in practice. An attacker who can block the check has removed it.

This is why short-lived certificates increasingly matter. A certificate valid for days rather than years does not need revocation to be reliable, because expiry does the work — which also demands the automated issuance described under key rotation discipline.

What a CA compromise means

Any trusted CA can issue a certificate for any domain. That is the structural weakness of the public PKI: your security depends on every CA in every trust store, not just the one you chose.

A compromised or coerced CA can issue a valid certificate for your domain, and a client presented with it will accept it, because the chain is genuinely valid. This has happened, and it is why the following exist.

Certificate Transparency requires certificates to be logged in public append-only logs, and browsers reject those that are not. A misissued certificate is therefore visible, and domain owners can monitor for certificates issued for their names — the monitoring recommended under brand impersonation, and the single most useful defensive use of the public PKI.

CAA records in DNS declare which CAs may issue for a domain. CAs are required to check them, so it prevents accidental and casual misissuance by other authorities, though not a CA ignoring the rules.

Pinning ties a client to specific certificates or keys, rejecting anything else. It defeats CA misissuance entirely and it also defeats legitimate interception, which is why applications that pin cannot be inspected by a TLS proxy. HTTP-based pinning was withdrawn for browsers because a mistake bricks a site; application-level pinning remains common.

Exam angles

Know the hierarchy: an offline root signing online intermediates which issue end-entity certificates, structured so a compromised intermediate can be revoked while the root cannot be. Know chain validation as walking upward to a trusted root, checking signature, dates, name, key usage and revocation. Distinguish CRL, OCSP and OCSP stapling, and know that revocation checking commonly fails open. Recognize Certificate Transparency, CAA records and pinning as responses to the any-CA-can-issue-for-any-domain problem.