CertGuru

Root and intermediate certificate authorities

A root CA is a self-signed certificate that lives in your operating system's trust store and acts as a trust anchor. An intermediate CA is signed by the root and does the day-to-day work of issuing certificates. The split exists so the root's private key can stay offline: if an intermediate is compromised it can be revoked and replaced without every operating system and browser on earth needing an update. Servers must send their intermediates and must not send the root, because clients that trust the root already have it.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

The hierarchy # 

Root CA                    self-signed, in your trust store, key kept offline
|
+-- Intermediate CA       signed by the root, key online, does the issuing
      |
      +-- example.com     the certificate your server presents

Telling them apart #

A root signs itself
openssl x509 -in root-ca.crt -noout -subject -issuer
Expected output 
subject=C = US, O = Example CA, CN = Example Root CA
issuer=C = US, O = Example CA, CN = Example Root CA
An intermediate names its parent
openssl x509 -in intermediate.crt -noout -subject -issuer
Expected output 
subject=C = US, O = Example CA, CN = Example Intermediate CA
issuer=C = US, O = Example CA, CN = Example Root CA

Both have CA:TRUE, so that alone does not tell you which is which:

openssl x509 -in intermediate.crt -noout -ext basicConstraints
Expected output 
X509v3 Basic Constraints: critical
  CA:TRUE, pathlen:0

pathlen:0 is worth noticing — it means this CA may issue end-entity certificates but may not create further CAs beneath it.

Why the split exists #

A root private key is the most valuable object in the system. Anyone holding it can issue a certificate for any hostname on the internet, and every browser will accept it. So roots are generated in a ceremony, stored in hardware security modules, and kept physically offline.

If roots signed server certificates directly, that key would have to be online and used thousands of times a day. Instead the root signs a handful of intermediates once, and the intermediates take the operational risk.

The consequence that matters: a compromised intermediate can be revoked. Browsers and operating systems distribute revocation for intermediates routinely. A compromised root cannot be handled that way — it would require an update to every device, and devices that no longer receive updates would be stranded.

What the server sends #

Certificate Server sends it? Why
Leaf (yours) Yes It is the identity being presented
Intermediate Yes The client has no other way to get it
Root No Trusting clients have it; others gain nothing 
cat certificate.crt intermediate.crt > fullchain.crt

Omitting the intermediate is the most common TLS misconfiguration there is — see unable to get local issuer certificate.

Cross-signing #

An intermediate is sometimes signed by more than one root, so that older devices which only trust an old root and newer devices which trust a new one both build a valid path. This is how a new CA bootstraps trust on devices that will never receive a software update.

The practical consequence is that one certificate may have more than one valid chain, and different clients may build different ones. A chain that validates on your laptop can still fail on an old Android device.

Running your own #

The same structure works for an internal PKI, and for a small one the extra layer is often not worth it — signing directly from the root is simpler and the offline-root benefit only materialises if you actually keep it offline.

Frequently asked questions

How do I tell a root from an intermediate?
Compare subject and issuer. A root's are identical — it signed itself. An intermediate's issuer names the certificate above it. Both carry basicConstraints CA:TRUE, so that field does not distinguish them.
Why does my server need to send the intermediate?
Because clients only have roots. Without the intermediate, the client cannot connect your certificate to any root it trusts, and verification stops with error 20.
Should the root be in my server's chain file?
No. Clients that trust it already have it, so sending it wastes bandwidth on every handshake. Clients that do not trust it gain nothing from receiving it.
What happens when a root expires?
Everything under it stops validating, which is why roots are issued with 20-year-plus lifetimes and replacements are distributed years ahead. The Let's Encrypt DST Root CA X3 expiry in 2021 broke a large number of older devices for exactly this reason.

References

Related pages