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.
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.
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.
