A single certificate is never enough. Trust on the internet is built through chains, linked sequences of certificates that connect the one on your server all the way back to a root that your browser already trusts.
When your browser connects to a website over HTTPS, it does not simply accept the server's digital certificate at face value. Instead, it follows a chain of signatures, from the certificate on the server, through one or more intermediate certificates, all the way up to a root certificate that is already embedded in the browser's trust store. If every link in that chain checks out, the connection is trusted. If any link is broken, the connection fails.
This mechanism, the certificate chain (or chain of trust), is what makes PKI scalable. A handful of root CAs can vouch for thousands of intermediate CAs, which in turn can issue millions of end-entity certificates. No single authority needs to sign every certificate in the world. Trust is delegated, layered, and verifiable at every step.
Understanding how chains work is not just academic. Misconfigured chains are one of the most common causes of TLS errors, certificate-related outages, and failed integrations. If you have ever seen a browser warning that says "the certificate is not trusted" (even though the certificate itself is valid), the problem was almost certainly a broken chain.
A certificate chain is an ordered sequence of certificates, each one signing the next, from the trust anchor down to the certificate presented by the server or device. There are typically three levels:
At the top of the chain sits the root Certificate Authority. The root CA's certificate is self-signed: it is signed with its own private key, because there is no higher authority to vouch for it. Instead, trust in a root CA comes from its inclusion in trust stores maintained by OS and browser vendors. Root CAs are kept offline, their keys stored in HSMs, and they are used only to sign intermediate CA certificates.
Intermediate CAs (also called subordinate CAs) are signed by the root CA. They sit in the middle of the chain and do the actual work of issuing end-entity certificates. This layer exists for security: if an intermediate CA is compromised, the root can revoke its certificate without destroying the entire PKI. There can be one or multiple intermediate levels, though most public PKIs use one or two.
This is the certificate installed on the server, device, or application. It is signed by an intermediate CA. The end-entity certificate contains the server's public key, its domain name (in the Subject or SAN fields), and the issuer information that points to the intermediate CA. It cannot sign other certificates; it is the "leaf" of the chain.
When a server presents its certificate during a TLS handshake, it also sends the intermediate certificate(s). The client then builds the chain upward: leaf to intermediate to root. If the root is in the client's trust store and every signature in the chain is valid, trust is established.
When a client (browser, application, or operating system) receives a certificate, it performs a series of checks to validate the chain. Here is the process broken down:
The client assembles the certificate chain by matching each certificate's Issuer field with the Subject field of the next certificate up. It starts with the end-entity certificate and works upward until it reaches a self-signed root.
For each certificate in the chain, the client uses the issuer's public key to verify the digital signature. If the signature on the end-entity certificate can be verified with the intermediate CA's public key, and the intermediate's signature can be verified with the root's public key, the chain is cryptographically sound.
Every certificate in the chain must be within its validity period (between its "Not Before" and "Not After" dates). If any certificate has expired or is not yet valid, the chain validation fails, even if the leaf certificate itself is current.
The client verifies that each certificate's extensions permit its role. For instance, the basicConstraints extension on an intermediate must have CA:TRUE. The keyUsage extension must include keyCertSign for certificates that sign other certificates. Learn more in the X.509 standard chapter.
Finally, the client verifies that the root certificate at the top of the chain is present in its trust store. If it is, the entire chain is trusted. If it is not (for example, because the root belongs to a private CA that the client has not been configured to trust), the validation fails and the user sees a certificate warning.
A trust store is a collection of root CA certificates that a system considers trustworthy. Every browser, operating system, and many applications maintain their own trust store. When a certificate chain is validated, the final check is whether the root CA at the top of the chain exists in the trust store being used.
Firefox uses its own trust store (managed by Mozilla's Root Program). Chrome and Edge rely on the operating system's trust store on most platforms, though Chrome is migrating to its own Chrome Root Store. Safari uses the Apple trust store. Each program has its own inclusion criteria and audit requirements.
Windows maintains its Trusted Root Certification Authorities store, macOS uses the System Keychain, and Linux distributions typically use a shared CA bundle (e.g., /etc/ssl/certs). Applications that do not ship their own trust store inherit trust from the OS.
Public root CAs must pass stringent audits (WebTrust for CAs, ETSI EN 319 411) and comply with the CA/Browser Forum Baseline Requirements. The application process can take over a year. Once accepted, the root is distributed to billions of devices via OS and browser updates.
For private PKI, organizations distribute their own root CA certificate to managed devices via Active Directory Group Policy, MDM profiles, configuration management (Ansible, Puppet), or manual installation. This is how internal services are trusted without relying on public CAs.
In a straightforward PKI hierarchy, trust flows in one direction: from root to intermediate to leaf. But real-world deployments sometimes need to connect separate PKI hierarchies so that certificates from one hierarchy are trusted by systems in another. There are two main approaches.
Cross-certification occurs when two CAs issue certificates to each other. If CA-A signs a certificate for CA-B, then systems that trust CA-A will also trust certificates issued by CA-B, and vice versa, if CA-B signs a certificate for CA-A. This creates mutual trust without requiring a shared root. It is commonly used when two organizations merge, when a government needs to interoperate with a commercial CA, or when transitioning between old and new root CAs.
Bridge CAs take this concept further. A bridge CA acts as a central trust hub that cross-certifies with multiple independent CAs. Rather than each CA cross-certifying with every other CA (which grows quadratically), each CA only needs to cross-certify with the bridge. The U.S. Federal Bridge Certification Authority (FBCA) is a well-known example, connecting numerous federal agency PKIs into a single interoperable trust framework.
Both mechanisms add complexity to chain building and validation. A single certificate can now have multiple valid chains: one through the direct hierarchy and another through a cross-certificate path. Modern TLS libraries handle this automatically, but it is important to understand when troubleshooting unexpected trust behavior.
Certificate chain problems are among the most frequent causes of TLS errors and outages. Here are the issues you are most likely to encounter:
This is the most common chain problem. A server presents its leaf certificate but fails to include the intermediate CA certificate(s). Without the intermediate, the client cannot build a path to the root, and the connection fails. Some browsers work around this by caching intermediates from previous connections (a process called AIA fetching), but not all clients support this. The fix is straightforward: configure your server to send the complete chain.
Root CA certificates typically have very long validity periods (20-30 years), and intermediates last 5-10 years. But they do expire. When a root or intermediate expires, every certificate beneath it in the chain becomes untrusted, even if the leaf certificates themselves are still within their validity period. The IdenTrust DST Root CA X3 expiration in 2021, which affected millions of older devices, is a well-known example.
The TLS specification requires certificates to be sent in order: leaf first, then intermediates, with the root optionally included last. Some servers send certificates in the wrong order. While most modern TLS libraries can reorder the chain automatically, older or stricter implementations may reject a misordered chain. Correct ordering eliminates ambiguity.
If the root CA at the top of the chain is not in the client's trust store, the entire chain is untrusted. This commonly happens when a private CA's root has not been distributed to all endpoints, when a root is removed from a trust store program, or when a client application uses a different trust store than expected (e.g., a Java application using its own cacerts keystore).
Most chain issues are preventable with proper configuration and monitoring. The challenge grows with scale: when you manage thousands of certificates across hundreds of servers, a single misconfigured chain can slip through unnoticed until it causes a production incident.
Detect broken chains automatically: Evertrust CLM continuously monitors your deployed certificates and flags chain issues (missing intermediates, expired CAs, and incorrect configurations) before they cause outages.
Map your entire CA hierarchy: Visualize the relationships between root CAs, intermediate CAs, and end-entity certificates across your infrastructure. See which certificates depend on which CAs, and get early warnings when any CA certificate approaches expiration.
Validate chains at scale: Evertrust CLM performs chain validation across your entire certificate inventory, identifying trust issues that would be impossible to catch manually when managing thousands of certificates.
Prevent outages proactively: Real-time alerting on chain anomalies, expiring intermediates, and trust store changes ensures your team can act before users are impacted.
