The chain of trust refers to a TLS/SSL certificate and how it is linked back to a trusted certificate authority. It is made up of a list of certificates that begins with a server’s certificate and ends with the root certificate. For a TLS/SSL certificate to be trusted, its signature has to be traceable back to its root CA, or the trust root. That means that in a certificate chain of trust, every certificate should be signed by the entity that is identified by the next certified along the chain, from server to intermediate to root.
A certificate chain of trust is a key function of the Public Key Infrastructure (PKI), which supports a number of security-related services, including data confidentiality, data integrity, and end-entity authentication. Fundamentally, these services are based on the proper use of public/private key pairs. The public component of this key pair is issued in the form of a public key certificate and, in association with the appropriate algorithm(s), it may be used to verify a digital signature, encrypt data, or both.
A public-key certificate is a signed statement that is used to establish an association between an identity and a public key. This is called a machine identity. The entity that vouches for this association and signs the certificate is the issuer of the certificate and the identity whose public key is being vouched for is the subject of the certificate. In order to associate the identity and the public key, a chain of certificates is used. This certificate chain of trust is also called the certification path.
What is a certificate chain?
A certificate chain is a list of certificates (usually starting with an end-entity certificate) followed by one or more CA certificates (usually the last one being a self-signed certificate), with the following properties:
- The issuer of each certificate (except the last one) matches the subject of the next certificate in the list.
- Each certificate (except the last one) is supposed to be signed by the secret key corresponding to the next certificate in the chain (i.e. the signature of one certificate can be verified using the public key contained in the following certificate).
- The last certificate in the list is a trust anchor: a certificate that you trust because it was delivered to you by some trustworthy procedure. A trust anchor is a CA certificate (or more precisely, the public verification key of a CA) used by a relying party as the starting point for path validation.
In RFC 5280 the certificate chain or chain of trust is defined as “certification path”. In the words of RFC 5280 “In general, a chain of multiple certificates may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.”
In other words, the chain of trust refers to your TLS/SSL certificate and how it is linked back to a trusted Certificate Authority. In order for an TLS certificate to be trusted, it has to be traceable back to the trust root it was signed off, meaning all certificates in the chain—server, intermediate and root—need to be properly trusted. There are three parts to the chain of trust:
Image 1: Certificate Chain for Venafi
- Root Certificate. A root certificate is a digital certificate that belongs to the issuing Certificate Authority. It comes pre-downloaded in most browsers and is stored in what is called a “trust store.” The root certificates are closely guarded by CAs.
- Intermediate Certificate. Intermediate certificates branch off root certificates like branches of trees. They act as middle-men between the protected root certificates and the server certificates issued out to the public. There will always be at least one intermediate certificate in a chain, but there can be more than one.
- Server Certificate. The server certificate is the one issued to the specific domain the user is needing coverage for.
Certificate chains are used in order to check that the public key and other data contained in an end-entity certificate (the first certificate in the chain) effectively belong to its subject. In order to ascertain this, the signature on the end-target certificate is verified by using the public key contained in the following certificate, whose signature is verified using the next certificate, and so on until the last certificate in the chain is reached. As the last certificate is a trust anchor, successfully reaching it will prove that the end-entity certificate can be trusted.
The description in the preceding paragraph is a simplified view on the certification path validation process as defined by RFC 5280, which involves additional checks, such as verifying validity dates on certificates, looking up CRLs, and more.
How do certificate chains work?
When you install your TLS certificate, you’ll also be sent an intermediate root certificate or bundle. When a browser downloads your website’s TLS certificate upon arriving at your homepage, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate. If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate. Proper certificate management ensures that every certificate is valid and chaining properly.
How are certificate chains built?
If we examine how certificate chains are built and validated, we will note that a solid certificate can be part of different valid certificate chains. This is because several CA certificates can be generated for the same subject and public key, but can be signed with different private keys (from different CAs or different private keys from the same CA). Although a single X.509 certificate can have only one issuer and one CA signature, it can be validly linked to more than one certificate, building completely different certificate chains. This process is common in cross-certification.
This process is defined in the ITU X.509 Standard as follows:
“Cross certificate is a certificate where the issuer and the subject are different CAs. CAs issue certificates to other CAs either as a mechanism to authorize the subject CA's existence (e.g. in a strict hierarchy) or to recognize the existence of the subject CA (e.g. in a distributed trust model). The cross-certificate structure is used for both of these.”
Certification path construction involves discovery of a "chain of certificates" between the end-entity certificate and a recognized trust anchor. Certification paths can be constructed in the forward direction (i.e., from the end-entity certificate to a recognized trust anchor) or they can be constructed in the reverse direction (i.e., from a recognized trust anchor to the end-entity certificate).
In order to understand the certification path construction, it is important to review how a public key certificate is structured. Image 2 below shows the structure of a X.509 certificate.
Image 2: X.509 Public Key Certificate Structure. Source
At the most basic level, a candidate certification path must "name chain" between the recognized trust anchor and the target certificate (i.e., the end-entity certificate). Working from the trust anchor to the target certificate, this means that the Subject Name in one certificate must be the Issuer Name in the next certificate in the path, and so on. Image 3 below helps to illustrate this concept. In this example, the path begins with a self-signed certificate that contains the public key of the trust anchor. The path ends with the end-entity certificate. All other certificates within the path are referred to as intermediate CA certificates. Note that every certificate in the chain except for the last one is a CA certificate.
Image 3: Certificate Chain. Source
One last topic. In the paragraph above we have mentioned two ways of constructing a certification path: forward and reverse. Which one is the best? The study of Elley et.al. of Sun Labs have reached the conclusion that “For certain trust models, such as a hierarchical trust model, building in the forward direction is more effective because we can take advantage of the fact that every entity has only one certificate issued for it by its superior. For more general trust models, however, we conclude that building in the reverse direction is more effective because it allows us to perform superior validation of the certification path as we are building it, thereby allowing us to more quickly reject certificates that are not useful in constructing a valid certification path. Building in the reverse direction allows us to more effectively process name constraints, policies, signatures, and CRL-based revocation. It also allows us to more effectively detect useless loops of certificates.”
Troubleshooting certificate chain issues
If the certificate chain hasn’t been configured correctly, you will receive errors regarding your certificate’s chain of trust. Here are some things to consider if you receive an error relating to your trust chain.
- Was your TLS certificate issued by a trusted CA? If not, your TLS certificate will not be trusted by browsers. This would also be an issue if you self-signed your certificate.
- Did you install your intermediate certificates properly? While some browsers will try to fill in any gaps in the certificate chain, you don’t want to leave things to chance. Make sure that you successfully install all intermediate certificates at the time you install your TLS certificate.
- Is your server configured correctly? Having installed your TLS certificate and any accompanying intermediates doesn’t mean you’ve configured your server properly.
(This post has been updated. It was originally published on August 26, 2019.)
Related posts
