In legal terminology, a chain of custody is a way to ensure safety, legitimacy, and to simply know where and with whom sensitive information has been (and who has had access to it). In the world of digital certificates, a chain of trust functions somewhat similarly, but with the same intent: to form a linked path of validation and verification from a trust anchor down to an end-entity certificate.
A chain of trust consists of several parts:
- A trust anchor, which is the originating certificate authority (CA).
- At least one intermediate certificate, serving as “insulation” between the CA and the end-entity certificate.
- The end-entity certificate, which is used to validate the identity of an entity such as a website, business, or person.
With that intro, let’s take a closer look at chains of trust:
In SSL/TLS, S/MIME, code signing, and other applications of X.509 certificates, a hierarchy of certificates is used to verify the validity of a certificate’s issuer. This hierarchy is known as a chain of trust. In a chain of trust, certificates are issued and signed by certificates that live higher up in the hierarchy.
It’s easy to see a chain of trust for yourself by inspecting an HTTPS website’s certificate. When you check an SSL/TLS certificate in a web browser, you’ll find a breakdown of that digital certificate’s chain of trust, including the trust anchor, any intermediate certificates, and the end-entity certificate. These various points of verification are backed up by the validity of the previous layer or “link,” going back to the trust anchor.
The example below shows the chain of trust from SSL.com’s website, leading from the end-entity website certificate back to the root CA, via one intermediate certificate:
The root certificate authority (CA) serves as the trust anchor in a chain of trust. The validity of this trust anchor is vital to the integrity of the chain as a whole. If the CA is publicly trusted (like SSL.com), the root CA certificates are included by major software companies in their browser and operating system software. This inclusion ensures that certificates in a chain of trust leading back to any of the CA’s root certificates will be trusted by the software.
Below, you can see the trust anchor from SSL.com’s website (
SSL.com EV Root Certification Authority RSA R2):
The root CA or trust anchor has the ability to sign and issue intermediate certificates. Intermediate certificates (also known as intermediate, subordinate, or issuing CAs) provide a flexible structure for conferring the validity of the trust anchor to additional intermediate and end-entity certificates in the chain. In this sense, intermediate certificates serve an administrative function; each intermediate can be used for a specific purpose — such as issuing SSL/TLS or code signing certificates — and can even be used to confer the root CA’s trust to other organizations.
Intermediate certificates also provide a buffer between the end-entity certificate and the root CA, protecting the private root key from compromise. For publicly trusted CAs (including SSL.com), the CA/Browser forum’s Baseline Requirements actually prohibit issuing end-entity certificates directly from the root CA, which must be kept securely offline. This means that any publicly trusted certificate’s chain of trust will include at least one intermediate certificate.
In the example shown below,
SSL.com EV SSL Intermediate CA RSA R3 is the sole intermediate certificate in the SSL.com website’s chain of trust. As the certificate’s name suggests, it is only used for issuing EV SSL/TLS certificates:
The end-entity certificate is the final link in the chain of trust. The end-entity certificate (sometimes known as a leaf certificate or subscriber certificate), serves to confer the root CA’s trust, via any intermediates in the chain, to an entity such as a website, company, government, or individual person.
An end-entity certificate differs from a trust anchor or intermediate certificate in that it cannot issue additional certificates. It is, in a sense, the final link as far as the chain is concerned. The example below shows the end-entity SSL/TLS certificate from SSL.com’s website:
With this certificate installed on the web server, SSL.com’s website will be trusted by your browser, all thanks to the unbroken chain of trust from SSL.com’s EV root, through the intermediate certificate, to the end-entity certificate itself.
Why does a chain of trust matter?
A chain of trust ensures security, scalability, and standards compliance for CAs. It also ensures privacy, trust, and security for those who rely upon end-entity certificates, such as website operators and users.
It is important for website owners and other users of end-entity certificates to understand that a complete chain of trust is necessary for their certificate to confer a CA’s trust successfully. For information on diagnosing and troubleshooting browser errors resulting from an incomplete chain of trust, please see our article on installing intermediate certificates and guide to browser error messages.Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.