Root vs Intermediate Certificates Explained

Every SSL certificate is part of a chain that connects it to a trusted root certificate. The chain typically has three levels: a root certificate at the top, an intermediate certificate in the middle, and your website's end-entity certificate at the bottom. Understanding the difference between root and intermediate certificates is essential for proper SSL installation, troubleshooting trust errors, and understanding how the certificate authority system works.

Most SSL problems that users report as "certificate errors" are actually caused by missing intermediate certificates, not problems with the end-entity certificate itself. This guide explains what each certificate level does, why the chain exists, and how to fix issues when the chain is broken. For the full chain walkthrough, see SSL Certificate Chain Explained.

Root Certificates

A root certificate is a self-signed certificate issued by a root certificate authority (CA). It sits at the top of the chain of trust and is the ultimate trust anchor.

What Makes Root Certificates Special

Self-signed. Root certificates are signed by the CA's own private key, not by a higher authority. The CA essentially vouches for itself. This is why root certificates must be explicitly trusted -- there is no external party validating them.

Pre-installed in trust stores. Root certificates are embedded in your browser and operating system by the browser/OS vendor. When you install Chrome, Firefox, or Windows, the root certificates of dozens of trusted CAs are included. This is the bootstrap of trust: you trust these CAs because the browser vendor vetted them and included their root certificates.

Kept offline. The private key for a root certificate is extraordinarily valuable. If compromised, an attacker could issue trusted certificates for any domain in the world. Root CA private keys are stored in hardware security modules (HSMs) in physically secured facilities. They are rarely used directly -- instead, they sign intermediate certificates, which do the day-to-day work.

Long lifetimes. Root certificates are valid for 20-30 years or more. Changing root certificates is disruptive because it requires every browser and OS to update their trust stores. Root certificates are issued infrequently.

Trust Store Contents

A typical browser or OS trust store contains 100-150 root certificates from various CAs. The major root programs are:

• Mozilla NSS Root Store: Used by Firefox and many Linux distributions. Maintained by Mozilla.
• Apple Root Certificate Program: Used by Safari, iOS, and macOS.
• Microsoft Trusted Root Certificate Program: Used by Edge, Chrome on Windows, and Windows.
• Google Chrome Root Store: Chrome is transitioning to its own root store (Chrome Root Store).

Each program has requirements CAs must meet to be included, including regular audits and compliance with the CA/Browser Forum Baseline Requirements.

Intermediate Certificates

An intermediate certificate is signed by a root certificate (or by another intermediate) and is used to sign end-entity certificates. Intermediate CAs are the workhorses of the PKI system.

Why Intermediate Certificates Exist

Security isolation. If a root CA signed end-entity certificates directly, the root's private key would need to be used frequently. Each use is a risk. By signing only intermediate certificates (an infrequent operation), the root key stays safely offline. The intermediate's private key does the daily work of signing website certificates.

Damage containment. If an intermediate CA's private key is compromised, only that intermediate needs to be revoked. The root certificate remains trusted, and certificates signed by other intermediates under the same root are unaffected. If a root key were compromised, every certificate under that root would be untrusted.

Operational flexibility. A root CA can create multiple intermediate CAs for different purposes: one for DV certificates, one for OV certificates, one for code signing, etc. Each intermediate can have different policies and security requirements.

Cross-signing. CAs sometimes use intermediate certificates to cross-sign with other root CAs. Let's Encrypt, for example, had its certificates cross-signed by IdenTrust's root certificate to gain broad trust while building trust for its own root.

Intermediate Certificate Properties

• Signed by the root CA's private key (or by a higher intermediate).
• Contains a CA:TRUE flag in the Basic Constraints extension, indicating it can sign other certificates.
• Has a shorter lifetime than root certificates (typically 5-15 years).
• Its private key is stored securely but is used more frequently than a root key.
• Must be included in the certificate chain sent by the server.

The Chain of Trust

When a browser verifies your SSL certificate, it builds a chain:

End-Entity Certificate (your website's certificate)
  |-- signed by -->
Intermediate Certificate
  |-- signed by -->
Root Certificate (in browser's trust store)

The browser verifies each link:

1. Is the end-entity certificate signed by the intermediate? (Check the signature using the intermediate's public key.)
2. Is the intermediate signed by the root? (Check the signature using the root's public key.)
3. Is the root in the trust store? (Look it up.)

If all checks pass, the chain is valid and the certificate is trusted.

Multiple Intermediates

Some chains have more than one intermediate:

End-Entity Certificate
  |-- signed by -->
Intermediate Certificate 2
  |-- signed by -->
Intermediate Certificate 1
  |-- signed by -->
Root Certificate

This adds another level of indirection but works the same way. Each link in the chain is verified.

Common Problems

Missing Intermediate Certificate

This is the most common SSL installation error. The server sends only the end-entity certificate but not the intermediate. Some browsers (particularly Chrome and Firefox on desktop) can work around this by fetching the intermediate certificate using the Authority Information Access (AIA) extension in the end-entity certificate. But other clients (curl, older browsers, mobile browsers, API clients, and automated tools) do not fetch intermediates automatically and report a trust error.

Symptoms:

• Certificate works in Chrome on desktop but fails in curl, Python requests, or mobile browsers.
• SSL checkers report "incomplete chain" or "missing intermediate."

Fix: Install the full certificate chain on your server. Your CA provides the intermediate certificate(s) as part of the certificate delivery. Concatenate them in the correct order:

cat your-certificate.crt intermediate.crt > fullchain.crt

The order matters: end-entity certificate first, then intermediate(s), from bottom to top of the chain.

Wrong Intermediate Certificate

Installing an intermediate certificate from a different CA or from the wrong issuance hierarchy causes chain validation to fail. The signatures will not match.

Fix: Use the exact intermediate certificate provided by your CA for your specific certificate. Do not mix intermediates from different CAs or different certificate products.

Expired Intermediate Certificate

Intermediate certificates have expiration dates. If an intermediate expires, every certificate it signed becomes untrusted, even if the end-entity certificates have not expired.

CAs manage intermediate certificate lifetimes and replace them before expiration. But if your server has a cached copy of an old intermediate, you may need to update it.

Fix: Download the current intermediate certificate from your CA and update your server configuration.

Sending the Root Certificate

Some server configurations include the root certificate in the chain sent to browsers. This is unnecessary (browsers already have root certificates in their trust stores) and wastes a small amount of bandwidth, but it does not cause errors. Most SSL checkers will note it as a minor issue.

Checking the Certificate Chain

Using OpenSSL

openssl s_client -connect example.com:443 -showcerts

This shows every certificate in the chain sent by the server. You should see your end-entity certificate and one or more intermediate certificates.

Using an SSL Checker

Online SSL checkers like SSL Certificate Expiry and Qualys SSL Labs display the complete certificate chain and flag issues like missing intermediates, wrong order, or expired certificates.

Verifying the Chain Locally

openssl verify -CAfile root.crt -untrusted intermediate.crt your-certificate.crt

If the chain is valid, OpenSSL outputs your-certificate.crt: OK.

For more verification methods, see How to Check SSL Certificate and How to Check SSL with OpenSSL.

Cross-Signing

Cross-signing is a technique where a certificate is signed by multiple CAs. This is used when a new CA needs to be trusted by older browsers and operating systems that do not yet have the new CA's root certificate in their trust stores.

Let's Encrypt's history illustrates this. When Let's Encrypt launched, its own root (ISRG Root X1) was not in most trust stores. To be trusted immediately, Let's Encrypt had its intermediate (Let's Encrypt Authority X3) cross-signed by IdenTrust's DST Root CA X3, which was already widely trusted. This meant Let's Encrypt certificates were trusted through the IdenTrust chain even on old devices.

Over time, ISRG Root X1 was added to trust stores, and the cross-signing dependency was reduced. As of 2024, Let's Encrypt's own root is trusted by virtually all active browsers and operating systems.

References

1. RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," May 2008. https://datatracker.ietf.org/doc/html/rfc5280
2. CA/Browser Forum, "Baseline Requirements," https://cabforum.org/baseline-requirements/
3. Mozilla, "CA Certificate Program," https://wiki.mozilla.org/CA
4. Let's Encrypt, "Chain of Trust," https://letsencrypt.org/certificates/