A root CA is a self-signed trust anchor that lives in every browser and operating system trust store. Intermediate CAs sit one or more layers below it, do the day-to-day issuance, and keep the root offline. This guide covers two-tier and three-tier hierarchies, BasicConstraints and name constraints, key ceremonies, and the operational controls RFC 5280 and the CA/Browser Forum expect.
A root certificate authority is a self-signed trust anchor: the operating system, browser, or device trust store recognises it directly, and no higher authority is needed to vouch for it. Every other certificate ever issued in a hierarchy ultimately derives its credibility from that single root key, which is why root operators treat it almost like nuclear material — generated once, stored offline, used a handful of times across its lifetime.
Intermediate CAs exist because using the root directly is a bad idea. By signing one or more subordinate CAs and then locking the root away, an operator can keep day-to-day issuance running on the intermediates while preserving an offline, recoverable trust anchor. The same structure also makes segmentation possible: one intermediate for public TLS, another for internal mTLS, another for code signing, each with its own policy, profile, and revocation scope. If any intermediate is compromised, it can be revoked and replaced without uninstalling roots from millions of devices.
The walk back up that chain — from end-entity certificate, through intermediates, to the root in the trust store — is what X.509 path validation does on every TLS handshake. The mechanics of that walk are covered in certificate chains and trust and the field-level structure in X.509. This guide focuses on the other side of the same problem: how to design the hierarchy that produces a clean, validatable chain in the first place. Everything that follows is anchored in RFC 5280, the IETF profile of X.509 that defines what a CA certificate actually is.
A working PKI is not a flat list of issuers; it is a small tree with very specific rules about which node is allowed to sign which. RFC 5280 encodes those rules in two extensions that sit on every CA certificate: `basicConstraints` says whether the certificate may issue further certificates at all, and `pathLenConstraint` caps how many intermediate CAs may appear below it. Almost every architectural decision a PKI operator makes — two-tier or three-tier, one intermediate or several, regional or by use case — comes back to how those two extensions are populated on each tier.
Before debating hierarchies, it helps to be precise about what the three tiers are and how they differ at the certificate level.
The interesting property of this structure is that compromise blast radius is contained at each level. A leaked end-entity key burns one service. A compromised intermediate burns everything that intermediate ever issued, but the root is untouched and a replacement intermediate can be signed within a single key ceremony. A compromised root burns the entire PKI and triggers a trust store update across every device on the planet — which is why the root is the thing that never goes online.
The root is a self-signed certificate whose Subject and Issuer fields are identical. It carries `basicConstraints: CA:TRUE` with `pathLenConstraint` typically set to 1 (for a two-tier PKI) or 2 (for a three-tier PKI), and `keyUsage: keyCertSign, cRLSign`. Trust in a root never comes from a signature — it comes from the fact that an operating system, browser, or device trust store has been shipped with that exact certificate (or its public key) pre-installed. Roots are generated once, kept offline, used to sign a small number of subordinate certificates and CRLs, and otherwise left untouched. Public TLS roots typically have validity periods of 20 to 25 years; some enterprise private roots run longer.
An intermediate carries `basicConstraints: CA:TRUE` and is signed by the root (or, in a three-tier PKI, by a policy CA above it). Its `pathLenConstraint` is usually 0, meaning it can issue end-entity certificates but cannot itself sign further CAs. Intermediates do the actual work: they are online, integrated with the registration authority, automated through ACME, SCEP, EST or CMP, and they sign certificates by the thousand. They are also the layer that gets revoked when something goes wrong, because revoking an intermediate fails closed for everything it ever issued without touching the root.
The leaf in the tree. `basicConstraints: CA:FALSE` (or the extension may be omitted, with the same effect under RFC 5280). It can never sign another certificate — only the data it was issued for: a TLS handshake, an S/MIME message, a code signature, an mTLS authentication. End-entity validity is short by design: the CA/Browser Forum Baseline Requirements are scheduled to push public TLS leaves down to a maximum of 47 days by 2029, and most internal mTLS deployments already run far shorter than that. Short leaf lifetimes are what let an operator tolerate a slow revocation path.
If a root could safely sign end-entity certificates directly, no one would bother with intermediates. They exist for three reasons that compound, and any PKI design that ignores them ends up rebuilding them later under pressure.
A useful frame is that the root is a long-term, low-frequency, high-impact key, and the intermediate is a medium-term, high-frequency, recoverable key. The two are not interchangeable, and conflating them — by signing leaves directly from a "root" or by treating an intermediate as if it were the trust anchor — is the original sin behind most messy PKI migrations.
Intermediates are the unit of revocation. If an issuing CA is compromised — its HSM mishandled, a signing operator phished, a software bug exposing the key — the operator revokes that intermediate's certificate, publishes the revocation via CRL and OCSP, and stands up a replacement signed by the same offline root. Every end-entity certificate that chained through the burned intermediate fails closed automatically, without anyone touching the root or pushing trust store updates. Revoking a root, by contrast, requires every browser and OS vendor to ship a software update, and the long tail of unpatched devices may never receive it.
Different certificate populations have different policies, different validity windows, and different audit requirements. Public TLS is governed by the CA/Browser Forum Baseline Requirements; document signing is governed by eIDAS; internal device certificates may be governed only by internal policy. Putting each population behind its own intermediate — and writing a distinct certificate policy and CPS for each — lets an operator audit and rotate each one independently. It also lets the issuing key live in the right HSM partition for that population, with the right operators authorised to use it.
A root's most expensive property is the cost of replacing it. Public TLS roots take years to propagate into trust stores, and old devices may pin to the old root for the rest of their service life. Intermediates have no such constraint — they live and die inside the lifetime of the root above them. That asymmetry is what lets an operator rotate intermediates on a regular cadence (every 5 to 10 years, or after a compromise) without ever asking trust store programmes to do anything.
Once an operator has accepted that the root and the issuing layer must be different keys, the next question is whether to insert a third layer — a policy CA — between them. The answer is almost always "no, but" — fine for most enterprises, necessary for some.
The right default for most organisations is two-tier. It gives full blast-radius containment, supports per-use-case segmentation through multiple issuing CAs, and keeps the offline ceremony count manageable. Three-tier earns its keep only when the policy boundary is real — when different parts of the organisation must demonstrably operate under different policies, with different auditors, different HSM partitions, and different signing officers — and when the cost of an extra offline layer is justified by that separation. Most teams who reach for three tiers because "more layers feels safer" end up with the same trust posture and double the procedures.
The CA/Browser Forum and most public root programmes assume a two-tier model for new public TLS hierarchies. WebTrust audits, by contrast, are agnostic about depth but very specific about the controls at each layer.
| Two-tier (Root → Issuing) | Three-tier (Root → Policy → Issuing) | |
|---|---|---|
| Layers | Offline root signs one or more online issuing CAs directly | Offline root signs offline policy CAs, which sign online issuing CAs |
| Operational complexity | Low: one offline root ceremony, online issuing CAs under HSM | High: separate key ceremonies for root and each policy CA, more procedures to maintain |
| Segmentation | By intermediate (public TLS / mTLS / code signing on different issuing CAs under the same root) | By policy CA (different organisational units, regulatory regimes, or subsidiaries kept under their own policy CA, with multiple issuing CAs underneath) |
| Typical user | SMB and most enterprises, internal device PKIs, mid-market public CAs | Governments, large financial groups, regulated multinationals, eIDAS QTSPs, root programmes that cross-certify other CAs |
| Path validation cost | 2 signature verifications + 1 trust anchor lookup | 3 signature verifications + 1 trust anchor lookup; slightly larger handshake; harder to misconfigure (more chain to forget to serve) |
| `pathLenConstraint` on root | 0 or 1 | 1 or 2 |
The CA-ness of a certificate is not a label — it is the combination of `basicConstraints`, `keyUsage`, and `pathLenConstraint` that an RFC 5280 verifier will check on every link in the chain. The cheapest sanity check on any PKI is to print those extensions and confirm that a leaf is a leaf, an intermediate is an intermediate, and the root is the root.
The second block is what an operator runs during a controlled key ceremony to issue an intermediate from an offline root. The commands look mundane; the procedures around them — air-gapped machine, video-recorded ceremony, M-of-N quorum on the HSM token — are what makes the resulting certificate trustworthy.
Name Constraints in that extensions file are doing real work: they tell every conforming RFC 5280 verifier to reject any leaf this intermediate ever signs that does not fall under `.corp.example.com` or `.internal.example`. That is enforcement at the cryptographic layer, not at the policy layer, and it is the single most underused control in private PKI.
# Inspect a root or intermediate certificate and confirm its CA extensions
openssl x509 -in intermediate.pem -noout -text \
| grep -A2 -E 'Basic Constraints|Key Usage|Subject:|Issuer:|Not Before|Not After'
# Expected on an intermediate:
# Issuer: CN=Example Root CA
# Subject: CN=Example Issuing CA 1
# X509v3 Basic Constraints: critical
# CA:TRUE, pathlen:0
# X509v3 Key Usage: critical
# Certificate Sign, CRL Sign
# Not Before / Not After spanning roughly 5 to 10 years
# Walk the chain from a server leaf back to the root and confirm path validation
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERT/,/-----END CERT/p' > served-chain.pem
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
-untrusted served-chain.pem served-chain.pem
# A clean output reads "OK" and implicitly confirms that:
# 1. each certificate is signed by the next one up,
# 2. each issuer carries CA:TRUE,
# 3. the pathLenConstraint is not exceeded,
# 4. the chain terminates at a root in the trust store.# On the offline root machine (HSM attached, no network), sign an issuing CA CSR.
# The extensions file pins pathLen=0, keyUsage, and optionally nameConstraints.
cat > issuing-ca.ext <<'EOF'
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
# Optional but recommended for private PKI: restrict what this CA can issue under.
nameConstraints = critical, permitted;DNS:.corp.example.com, permitted;DNS:.internal.example
crlDistributionPoints = URI:http://crl.example.com/root.crl
authorityInfoAccess = OCSP;URI:http://ocsp.example.com/
EOF
openssl ca -config root-ca.cnf \
-extfile issuing-ca.ext \
-in issuing-ca.csr \
-out issuing-ca.pem \
-days 3650 \
-notext -batch
# The root's private key, held in the HSM, never touches disk. After issuance,
# the root machine is shut down and re-sealed until the next ceremony.The controls below are not a wish list. They are the baseline that WebTrust auditors, CA/Browser Forum members, ANSSI for eIDAS qualified trust services, and most enterprise security teams will look for during a PKI assessment. None of them are exotic, but missing any one of them is usually enough to fail an audit or, worse, to leave a real attack path open.
A PKI that meets these five controls also tends to meet, almost for free, the requirements of the CA/Browser Forum Baseline Requirements, WebTrust for CAs, ETSI EN 319 411 (under eIDAS), and the relevant ISO 27001 controls. They are not five different programmes — they are the same controls written down by different bodies.
The root's private key must be generated inside, and never leave, a Hardware Security Module that is certified to FIPS 140-2 Level 3 at a minimum — preferably FIPS 140-3 Level 3 for new deployments, with Common Criteria EAL4+ where the regulatory regime requires it. The machine that hosts the root CA software is kept physically air-gapped: no network interface, removable media handled under dual control, powered on only during scheduled ceremonies. Online issuing CAs likewise sign through an HSM, but their machine is allowed to be online — the boundary that matters is the HSM's, not the OS's. See the HSM guide for the FIPS level hierarchy and integration patterns.
Name Constraints are the only mechanism that lets a relying party enforce, cryptographically, that a private intermediate cannot mint a certificate for `google.com`. Every private intermediate should carry a `nameConstraints` extension marked critical, with `permitted` subtrees scoped to the DNS suffixes, IP ranges, RFC822 domains, and Directory Names the CA is allowed to issue under. The extension is also what makes cross-certification safe — when one organisation's root signs another organisation's intermediate, name constraints bound the trust transfer to a specific namespace rather than handing over the whole internet. This is mandatory under several Federal PKI policies and increasingly expected in mature private PKIs.
`pathLenConstraint` caps the number of further CA certificates that may appear between a given CA and any end-entity certificate. On an issuing CA, that value should be 0: the CA can sign leaves, nothing else. On a policy CA in a three-tier model, it should be 1. On a root in a two-tier model, 0 or 1 depending on whether you ever want to add a layer later. Setting `pathLenConstraint` correctly prevents an intermediate that has been compromised, mis-issued, or cross-signed in error from being used as a launchpad for further sub-CAs. It is two bytes in the certificate; it is the cheapest defence in depth in the entire profile.
Match the validity of each tier to its operational reality. Public TLS roots last 20 to 25 years and are replaced only when the algorithm or key size is itself deprecated. Intermediates last 5 to 10 years and are rotated on a planned cadence — typically with overlapping issuing CAs so that new leaves come from the new intermediate while old leaves still validate. End-entity certificates for public TLS will be limited to 47 days from 2029 onward under the CA/Browser Forum's adopted timeline, which only works if the issuance path is fully automated — see automated certificate management and shorter certificate lifespans for the operational consequences.
Every operation on the offline root — initial generation, signing a new intermediate, signing a CRL, decommissioning — must follow a written ceremony script, be performed in the presence of at least two operators and an internal auditor, and require an M-of-N quorum on the HSM's authentication tokens (a typical configuration is 3-of-5 smart card holders required to authorise a signing operation). The ceremony is video-recorded, all artefacts (CSR, signed certificate, audit log, HSM activity log) are hashed and archived, and the recording is stored for the lifetime of the certificates that derive from the operation. This is what WebTrust and eIDAS audits actually verify, and it is what lets an organisation prove, years later, that a given intermediate was signed by the right people under the right policy.
Multi-tier hierarchies with full policy control — Evertrust PKI is built to operate two-tier and three-tier hierarchies as a first-class concept, with per-tier certificate profiles, name constraints, path length, key usage, and CRL/OCSP distribution points all expressed as policy rather than configuration files scattered across machines. Issuing CAs are segmented by use case (public TLS, internal mTLS, device, code signing) under the same governed root, with each one auditable and revocable on its own.
Native HSM integration on every tier — Root and issuing CA keys are generated inside a FIPS 140-2/140-3 Level 3 HSM and never leave it. Native integration with FIPS 140-2/3 Level 3 HSMs from the major vendors used in enterprise PKI deployments, as well as cloud KMS where the regulatory regime allows it, so the cryptographic boundary is exactly where the audit expects it to be.
Auditable key ceremonies and operations — Every action on a root or intermediate CA is logged, signed, and tied to an identified operator under M-of-N controls. Ceremony artefacts, CRLs, and revocation events are immutable and exportable, so WebTrust, eIDAS, NIS2, and DORA reviewers see a complete, tamper-evident record without anyone having to assemble evidence by hand at audit time.