The certificate 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 certifier along the chain, from server to intermediate to root.
A certificate chain of trust is a crucial aspect of Public Key Infrastructure (PKI), which underpins various security services like data confidentiality, integrity, and user authentication. These services fundamentally rely on the correct application of public/private key pairs. The public part of these pairs is provided as a public key certificate. Combined with the right algorithms, this certificate can be used for verifying digital signatures, encrypting data, or both.
A public-key certificate is essentially a documented and signed verification linking an identity to a public key, often referred to as a machine identity. The issuer of the certificate is the entity that confirms and signs this linkage. The subject of the certificate is the identity associated with the public key. A series of linked certificates, known as a certificate chain of trust or certification path, is used to establish and validate the connection between the identity and the public key.
PKI: Are You Doing It Wrong?
What is a certificate chain?
A certificate chain consists of a sequence of certificates, typically beginning with an end-entity certificate and followed by one or more CA (Certificate Authority) certificates, culminating in a self-signed certificate. Key characteristics include:
- The issuer of each certificate in the chain (except the last one) corresponds to the subject of the subsequent certificate.
- Each certificate (except the final one) is meant to be authenticated by the secret key associated with the next certificate in the chain, allowing the signature of one certificate to be verified using the public key in the next.
- The final certificate in the chain is a trust anchor: a trusted CA certificate obtained through a reliable method. This trust anchor, essentially the public verification key of a CA, serves as the foundational point for path validation by the relying party.
In RFC 5280 the certificate chain or certificate 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.”
The term "chain of trust" in the context of TLS/SSL certificates refers to the connection of your certificate to a trusted Certificate Authority (CA). For a TLS certificate to be considered trustworthy, it must have a clear path back to its root of trust, the original CA that validated it. This means that every certificate in the chain - including the server, intermediate, and root certificates - must be reliably authenticated. The certificate chain of trust consists of three key components:
Image 1: Certificate Chain for Venafi
- Root Certificate: This is a digital certificate issued by the Certificate Authority (CA). Most browsers come pre-installed with these root certificates, which are stored in a "trust store." CAs meticulously safeguard these root certificates.
- Intermediate Certificate: These certificates function like tree branches stemming from the root certificates. They serve as intermediaries, linking the secure root certificates to the server certificates that are distributed to the public. In any certificate chain, there's always at least one intermediate certificate, but sometimes there are multiple.
- Server Certificate: This certificate is specifically issued for the domain that requires coverage, provided to the end-user or the website
Certificate chains are used to check that the public key and associated data in an end-entity certificate (the initial certificate in the chain) genuinely correspond to its subject. This is done by validating the end-entity certificate's signature using the public key in the next certificate. This process continues, with each subsequent certificate's signature being verified by the following one, until the final certificate, a trust anchor, is reached. Successfully arriving at this trust anchor confirms the reliability and trustworthiness of the end-entity certificate.
The explanation given above offers a basic overview of the certification path validation process outlined in RFC 5280. However, RFC 5280 specifies a more comprehensive procedure, which includes further steps like confirming the validity dates of certificates, consulting Certificate Revocation Lists (CRLs), among other additional checks.
How do certificate chains work?
Upon installing your TLS certificate, you will receive an intermediate root certificate or a bundle. When a browser accesses your website and retrieves the TLS certificate, it starts the process of linking this certificate back to its root. This begins with the intermediate certificate and continues backtracking to a trusted root certificate. A valid certificate that successfully chains back to a trusted root will be accepted by the browser. Conversely, if the chain doesn't lead to a trusted root, the browser will display a warning. Effective certificate management is key to ensuring that each certificate is valid and correctly chained.
How are certificate chains built?
When delving into the construction and validation of certificate chains, it becomes apparent that a single certificate can be part of various valid chains. This scenario arises because multiple CA certificates for the same subject and public key can exist, each signed with different private keys from either various CAs or the same CA. While an individual X.509 certificate has only one issuer and one CA signature, it can be validly connected to several certificates, creating distinct certificate chains. This is a frequent occurrence in cross-certification scenarios.
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.”
The process of certification path construction involves finding a “chain of certificates” from the end-entity certificate to a recognized trust anchor. This can be done in two ways: either starting from the end-entity certificate and working towards a trust anchor (forward direction), or beginning with a trust anchor and tracing back to the end-entity certificate (reverse direction). Understanding this process requires familiarity with the structure of a public key certificate, exemplified by the X.509 certificate format as depicted in Image 2 below.
Image 2: X.509 Public Key Certificate Structure. Source
Fundamentally, a viable certification path must establish a "name chain" from a recognized trust anchor to the target certificate, or the end-entity certificate. This implies that, starting from the trust anchor, the Subject Name in a certificate should match the Issuer Name in the subsequent certificate in the path. Image 3 below demonstrates this idea. In this specific example, the path begins with a self-signed certificate holding the public key of the trust anchor and concludes with the end-entity certificate. The other certificates in this path are intermediate CA certificates. It's important to note that all certificates in the chain, except for the final one, are CA certificates.
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 encounter errors related to the trust chain of your certificate. Here are some things to address if you encounter trust chain errors:
- Verify the Certificate Authority (CA): Confirm that your TLS certificate has been issued by a trusted Certificate Authority (CA). If it hasn't, web browsers will not trust your TLS certificate. This is also a concern if you've self-signed your certificate.
- Ensure Correct Installation of Intermediate Certificates: It is imperative to install intermediate certificates accurately. While some browsers may attempt to fill gaps in the certificate chain, it is not advisable to rely on chance. Ensure the successful installation of all intermediate certificates when setting up your TLS certificate.
- Configure Your Server: Merely installing your TLS certificate and its associated intermediates represents just one aspect of the process. Equally critical is configuring your server correctly to seamlessly integrate with the certificate. Proper server configuration is essential to ensure that your TLS certificate operates as intended.
(This post has been updated. It was originally published on August 26, 2019.)
