Root CA vs Intermediate CA

A Root CA is the trust anchor at the top of a PKI hierarchy. Its certificate is self-signed and pre-installed in browser and OS trust stores. An Intermediate CA (also called an Issuing CA or Subordinate CA) sits between the Root and end-entity certificates. It receives its authority from the Root CA’s signature and performs the actual day-to-day certificate issuance. This separation exists for one reason: if the signing key is compromised at the intermediate level, you revoke the intermediate and issue a new one. If the Root is compromised, the entire hierarchy collapses.

Why it matters

• Damage containment — compromising an Intermediate CA is recoverable (revoke it, issue a new one). Compromising a Root CA is catastrophic (every certificate ever issued under it becomes untrusted).
• Operational security — Root CA private keys are stored in offline HSMs, air-gapped from networks. They’re used only to sign intermediate certificates — a ceremony that happens rarely (once per year or less).
• Scalability — a single Root can sign multiple Intermediates, each serving different purposes (TLS issuance, code signing, client auth) with different policies and constraints.
• Revocation granularity — you can revoke an Intermediate CA without affecting other Intermediates under the same Root. End entities under the revoked Intermediate are invalidated, but the rest of the hierarchy continues operating.
• Compliance — standards like WebTrust and ETSI require Root CA keys to be stored in FIPS 140-2 Level 3+ HSMs with strict ceremony controls. Intermediates have lighter (but still significant) requirements.

How it works

1. Root CA creation — a self-signed certificate is generated in an offline HSM during a key ceremony. The Root certificate is distributed to trust stores (browsers, OS, devices).
2. Intermediate CA signing — the Root CA signs the Intermediate CA’s certificate, granting it authority to issue end-entity certificates. Constraints (path length, name constraints, key usage) are embedded.
3. End-entity issuance — the Intermediate CA receives CSRs and signs end-entity certificates for servers, users, or devices. This happens online, automated, at scale.
4. Chain assembly — the server presents its end-entity certificate plus the Intermediate CA certificate. The client builds the chain up to the Root in its trust store.
5. Validation — the client verifies each signature in the chain: end-entity signed by Intermediate, Intermediate signed by Root, Root is in the trust store.
6. Revocation check — the client checks CRL/OCSP for the end-entity and the Intermediate. Root CAs are never checked via OCSP — they’re either trusted or removed from the store entirely.

In real systems

Let’s Encrypt chain:

• Root: ISRG Root X1 (self-signed, in trust stores)
• Intermediate: R3 (signs all Let’s Encrypt end-entity certificates)
• End entity: your domain certificate

When R3 approaches expiry, ISRG signs a new intermediate (R4, etc.) without touching the Root. End entities issued by R3 remain valid until their own expiry.

Microsoft AD CS (enterprise PKI): A typical deployment uses a 2-tier hierarchy. The Root CA is an offline Windows Server that’s powered on only for intermediate signing ceremonies. The Issuing CA is online, integrated with Active Directory, and auto-enrolls certificates for domain-joined machines, users, and services.

AWS Private CA:

aws acm-pca create-certificate-authority \
  --certificate-authority-type SUBORDINATE \
  --certificate-authority-configuration \
    "KeyAlgorithm=EC_prime256v1,SigningAlgorithm=SHA256WITHECDSA,Subject={CommonName=MyIntermediate}"

AWS manages the HSM-backed key storage. You create a subordinate (intermediate) CA and sign it with your own Root or another parent CA. AWS handles availability — you handle policy.

Where it breaks

Root CA compromise (DigiNotar, 2011) — attackers gained access to DigiNotar’s Root CA and issued fraudulent certificates for google.com, used to intercept Gmail traffic in Iran. Because the Root was compromised, every certificate DigiNotar ever issued became untrusted. Browser vendors removed DigiNotar from all trust stores within days. The company went bankrupt. This is why Root keys stay offline — a compromised Intermediate would have been revocable without destroying the entire CA.

Intermediate CA certificate expiry — the Intermediate CA certificate has its own validity period (typically 5-10 years). When it expires, every end-entity certificate it signed becomes unverifiable — even if those end-entity certs haven’t expired yet. The chain breaks at the intermediate link. This happened to Sectigo’s AddTrust External CA Root in May 2020, causing widespread outages for services that included the expired cross-sign in their chain. Monitoring must track intermediate expiry, not just end-entity expiry.

Operational insight

Cross-certification adds a layer of complexity that catches teams off guard. When a new Root CA needs to be trusted by older clients that don’t have it in their trust store, the new Root gets cross-signed by an existing trusted Root. This creates two valid chain paths for the same end-entity certificate. Clients may build either path depending on their trust store contents. When the cross-sign expires (as happened with Let’s Encrypt’s DST Root CA X3 cross-sign in September 2021), older clients that relied on that path suddenly fail — even though the primary chain via ISRG Root X1 is perfectly valid. If you serve certificates from a cross-signed hierarchy, test chain building on your oldest supported clients, not just modern browsers.

Related topics

• What is a Certificate Authority
• Understanding PKI
• How to Set Up 2-Tier PKI
• Certificate Lifecycle Stages
• What is a TLS Certificate