- Key Takeaways
- Why do PKI Hierarchies Separate Root and Intermediate CAs?
- How do Root CA and Intermediate CA Responsibilities Differ?
- How Does a Client Validate a Certificate Chain?
- What Happens When an IIntermediate CA is Compromised?
- How Encryption Consulting Helps
- Frequently Asked Questions
- Design a PKI Hierarchy Built to Contain Risk
A Root CA is the top-level, self-signed Certificate Authority that anchors trust in a PKI hierarchy, while an Intermediate CA is a subordinate CA, certified by the root, that issues end-entity certificates on its behalf so the root’s private key can stay offline.
A Root CA is the self-signed authority at the top of a certificate chain that every relying party must trust directly. An Intermediate CA sits between the root and end-entity certificates, issuing certificates day to day so the root CA’s private key can remain offline and protected, limiting exposure if a subordinate CA is ever compromised.
Key Takeaways
- A Root CA’s certificate is self-signed and must be present in a relying party’s trust store for any certificate beneath it to be trusted.
- Intermediate CAs exist mainly for risk isolation: keeping the root CA offline and air-gapped means a compromised intermediate can be revoked without invalidating the entire hierarchy.
- A typical enterprise PKI hierarchy uses three tiers: an offline root CA, one or more issuing (intermediate) CAs, and the end-entity certificates issued to servers, users, or devices.
- Revoking an intermediate CA’s certificate invalidates every certificate it issued, which is why organizations often run multiple intermediates segmented by use case (e.g., TLS vs. code signing).
- Root CA certificates carry no explicit Certificate Policies extension by default, since a wildcard “All Issuance Policies” is implied for self-signed root certificates.
Why do PKI Hierarchies Separate Root and Intermediate CAs?
Separating root and intermediate CAs isolates risk. The root CA’s private key is the most valuable secret in the entire PKI, since compromising it would let an attacker forge trust for anything beneath it. Keeping it offline, often in a physically secured vault and only powered on for scheduled key ceremonies, removes it from daily attack surface entirely. Intermediate CAs handle routine issuance instead, so a compromised intermediate can be revoked and replaced without rebuilding trust from scratch.
How do Root CA and Intermediate CA Responsibilities Differ?
| Aspect | Root CA | Intermediate CA |
|---|---|---|
| Signing | Self-signed | Signed by the root (or a higher intermediate) |
| Operational state | Offline, air-gapped between key ceremonies | Online, actively issuing certificates |
| Trust store presence | Must be directly trusted by relying parties | Trusted only via its chain to a trusted root |
| Typical validity period | 10-25 years | 3-10 years, shorter than the root |
| Impact if compromised | Catastrophic; entire hierarchy must be rebuilt | Serious but contained; revoke and reissue beneath a new intermediate |
How Does a Client Validate a Certificate Chain?
- The client receives the end-entity certificate along with any intermediate certificates the server presents.
- It checks the end-entity certificate’s issuer field and locates the intermediate that signed it.
- It verifies the intermediate’s own signature, tracing up the chain until it reaches a certificate already present in its trust store.
- If that trusted root is found and every signature in the chain validates, and no certificate in the chain is expired or revoked, the client accepts the connection.
What Happens When an IIntermediate CA is Compromised?
If an intermediate CA’s private key is compromised, its certificate must be revoked, which invalidates every certificate it issued. This is far less damaging than a root CA compromise, since the root can sign a new intermediate and reissue certificates under it without every relying party needing to update its trust store, which only needs to happen if the root itself is replaced.
How Encryption Consulting Helps
How Encryption Consulting HelpsPKI-as-a-Service and PKI Services design and operate multi-tier CA hierarchies, including offline root CA key ceremonies and segmented intermediate CAs by use case, so a compromised intermediate never threatens your entire trust chain. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
Can an end-entity certificate be issued directly by a Root CA?
Technically yes, but it is considered poor practice. Nearly all production PKI hierarchies issue end-entity certificates from an intermediate CA instead, keeping the root offline and reducing the blast radius if an issuing CA is ever compromised.
How many intermediate CAs should an organization run?
There is no fixed number, but many organizations segment intermediates by use case, for example one for TLS server certificates and another for code signing, so that revoking one intermediate does not affect certificates issued for an unrelated purpose.
Why is a Root CA kept offline?
A Root CA is kept offline because its private key anchors trust for the entire hierarchy. If it were online and compromised, an attacker could forge certificates for any domain or identity the CA is trusted to certify, requiring every relying party to remove that root from its trust store.
What is a certificate chain?
A certificate chain is the ordered sequence of certificates, from an end-entity certificate up through one or more intermediate CAs to a trusted root CA, that a relying party validates to confirm the end-entity certificate is trustworthy.
Design a PKI Hierarchy Built to Contain Risk
Take the next step Encryption Consulting’s PKI Services and PKI-as-a-Service design multi-tier CA hierarchies with properly isolated root and intermediate CAs. Explore PKI-as-a-Service to get started.
- Key Takeaways
- Why do PKI Hierarchies Separate Root and Intermediate CAs?
- How do Root CA and Intermediate CA Responsibilities Differ?
- How Does a Client Validate a Certificate Chain?
- What Happens When an IIntermediate CA is Compromised?
- How Encryption Consulting Helps
- Frequently Asked Questions
- Design a PKI Hierarchy Built to Contain Risk
