A root certificate is self-signed and sits at the very top of the chain of trust — it's the thing actually built into your browser or OS as an inherently trusted anchor. An intermediate certificate sits between the root and your certificate, signed by the root (or another intermediate) and used to sign end-entity certificates like the one on your website.
Why not sign directly from the root?
Root certificates are kept offline and heavily protected, because if a root's private key were ever compromised, every certificate that traces back to it would need to be distrusted — a catastrophic, internet-wide event. Intermediates exist as a buffer: they do the day-to-day signing work, and if one is ever compromised, only certificates it issued need to be revoked, not the entire root's history.
What this means practically
When you install a certificate, you almost always need to also install a "CA bundle" or "intermediate bundle" alongside it. Skipping that step is one of the most common causes of "not trusted" errors on some devices even though the certificate itself is completely valid — the server just isn't presenting the full chain needed to connect it back to a trusted root.
Why your server needs to present the intermediate, not just your certificate
Some browsers cache commonly-seen intermediate certificates and can complete the chain even if your server doesn't present it correctly — but a fresh client with no such cache, common on mobile devices or command-line tools, will reject the connection outright. This is why installing the full CA-provided bundle, not just your own certificate, is essential rather than optional.
How to check your own chain is complete
Running `openssl s_client -connect yourdomain.com:443 -showcerts` shows exactly what your server sends. If you only see one certificate in the output rather than your certificate followed by at least one intermediate, that confirms the bundle is missing and needs to be installed alongside your certificate.
Why root certificates are rotated so rarely compared to everything else in this ecosystem
Because a root's inclusion in browser trust stores takes years to achieve and root keys are kept in extremely protected, offline storage, roots are rotated far less frequently than intermediates or end-entity certificates — a root certificate commonly remains valid and in active use for well over a decade, unlike the 90-day to 398-day cycles common further down the chain.
Why some certificates chain through more than one intermediate
Certain CAs use two or more intermediate certificates in sequence between the root and your certificate, adding an extra layer of isolation — if a lower-level intermediate is ever compromised, only certificates it issued need revoking, not everything issued through that CA's entire hierarchy, containing the damage more precisely.
What a cross-signed intermediate actually solves
Some intermediates are signed by more than one root simultaneously, specifically to help a newer CA whose own root isn't yet trusted everywhere. This gives older clients a fallback trust path through an already-established root while the newer root gradually achieves broader trust-store inclusion on its own — Let's Encrypt used exactly this technique during its early years.
What this structure ultimately buys the entire ecosystem
The layered root-intermediate-leaf structure trades a small amount of added complexity for a large amount of risk containment — a compromise anywhere below the root affects only a bounded subset of certificates, rather than threatening the trust of everything the CA has ever issued, which is exactly the property that makes the whole system resilient enough to operate at internet scale.
Why this layered structure took time for the industry to standardize around
Early SSL deployments sometimes used simpler, flatter trust structures before the layered root-intermediate-leaf model became the near-universal standard — the layered approach won out specifically because it isolates risk more effectively than having roots sign end-entity certificates directly.
A closing thought
A quick closing thought: this layered structure, however abstract it might initially seem, is precisely what lets your browser extend trust to a brand-new certificate from a company it's never encountered before, based entirely on a chain of signatures traced back to a small, curated set of roots.