The certificate chain of trust is the ordered sequence of certificates, from an end-entity certificate through one or more intermediate certificates back to a trusted root, that a browser validates before trusting a website’s certificate.
The chain of trust links a server certificate to a trusted root certificate through one or more intermediate certificates. Each certificate in the chain is signed by the private key of the one above it, and a browser validates every signature back to the root before trusting the connection. If any link is missing, expired, or invalid, the browser rejects the certificate.
Key Takeaways
- A chain has three tiers: root, intermediate, and server. The root certificate anchors trust, the intermediate certificate bridges root and server, and the server certificate is what a browser actually receives.
- Root certificates are the most protected asset in a CA’s hierarchy. Root private keys are typically kept offline and air-gapped, since compromising the root would undermine every certificate the CA has ever issued.
- Intermediate certificates exist to limit blast radius. If an intermediate CA is compromised, only the certificates it issued are affected, not the entire trust hierarchy.
- Root programs, not individual browsers, decide which roots are trusted. Microsoft, Apple, Google, and Mozilla each run a root program with CA/Browser Forum baseline requirements a CA must meet to be included.
- A broken chain fails closed, not open. A certificate chain missing a valid link back to a trusted root causes the browser to distrust the site rather than trust it by default.
The Three Tiers of a Certificate Chain
Every certificate chain resolves into three roles: root, intermediate, and server (or end-entity) certificate.
| Tier | Role | Typical validity |
|---|---|---|
| Root certificate | Self-signed trust anchor for the entire hierarchy | Up to 25 years |
| Intermediate certificate | Signed by the root; issues end-entity certificates | Several years |
| Server (end-entity) certificate | Installed on the website or server a browser connects to | Up to 398 days today, shrinking toward 47 days by 2029 |
A browser validates this chain by checking that each certificate’s issuer field matches the subject of the certificate above it, all the way to a root certificate already present in its trust store.
Root Certificate Authorities vs Intermediate Certificate Authorities
Root and intermediate CAs play different roles in the same hierarchy, with very different security requirements.
- Root CAs are self-signed and sit at the top. A Root CA signs its own certificate and typically stays offline except to sign intermediate certificates or publish CRLs.
- Intermediate CAs are signed by the root and do the day-to-day issuing. Most end-entity certificates are actually signed by an intermediate CA, not the root directly.
- A root compromise is catastrophic; an intermediate compromise is contained. Revoking a compromised intermediate certificate only affects the certificates it issued, while a root compromise undermines the entire chain.
- Root CAs undergo the most extensive audits. Because the credibility of the whole ecosystem depends on the root, root CAs face the strictest verification and compliance requirements.
Why Root Programs Matter
Root programs run by Microsoft, Apple, Google, and Mozilla decide which Certificate Authorities are trusted by default.
Each root program requires CAs to meet CA/Browser Forum Baseline Requirements and undergo regular audits before their root certificate is added to the operating system or browser’s trust store. This is why a certificate chain that resolves to a root outside these programs, such as an internal Private CA’s root, is not trusted by public browsers even if every signature in the chain is technically valid.
Why New CAs Use Cross-Certificates
A new Certificate Authority typically cannot issue a root certificate that browsers trust immediately, so it borrows trust from an established CA first.
A new CA links its own certificate to an established CA’s already-trusted root through a cross-certificate, letting it issue trustworthy certificates while it works through the lengthy root program inclusion process. Once the new CA’s own root is validated and added to root stores, it can transition away from the cross-certificate and rely on its own root as the trust anchor.
How Encryption Consulting Helps
CertSecure Manager tracks the full certificate chain for every certificate an organization runs, flagging missing intermediates or chain misconfigurations before they cause browser trust errors. Encryption Consulting’s PKI-as-a-Service also supports building and operating properly structured root and intermediate CA hierarchies. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
What happens if a certificate chain is missing an intermediate certificate?
The browser cannot validate the path from the server certificate back to a trusted root, so it treats the certificate as untrusted, typically showing a warning or blocking the connection. This is one of the most common certificate configuration errors, since the intermediate certificate must be installed alongside the server certificate.
Why do root certificates stay offline?
A root certificate is the trust anchor for every certificate a CA has ever issued. If the root’s private key is compromised, an attacker could forge trusted certificates for any domain, so root CAs are kept offline and air-gapped except for the rare occasions they sign a new intermediate certificate or CRL.
What is the difference between a root CA and an intermediate CA?
A Root CA is self-signed and sits at the top of the hierarchy as the ultimate trust anchor. An Intermediate CA is signed by the root and handles the actual day-to-day issuance of end-entity certificates, which limits the impact if that intermediate is ever compromised.
Who decides which root certificates are trusted?
Root programs operated by Microsoft, Apple, Google, and Mozilla each maintain their own list of trusted root certificates. A Certificate Authority must meet CA/Browser Forum Baseline Requirements and pass regular audits to be included in these programs, which is what makes its certificates trusted by default in browsers and operating systems.
Keep Every Certificate Chain Valid
See CertSecure Manager in action to catch missing or misconfigured certificate chains before they cause a browser trust error.