Skip to main content
banner image
venafi logo

How Do Certificate Chains Work?

How Do Certificate Chains Work?

image of blue chain-links made of ones and zeroes to represent digital chains
August 26, 2019 | Guest Blogger: Anastasios Arampatzis

How Do Certificate Chains Work?

Public Key Infrastructure (PKI) 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. Certificate chain is also called certification path or chain of trust.
 

How much do you know about machine identities? Read Machine Identity Protection for Dummies.
 

What are Certificate Chains?


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

 

  1. 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.
  2. 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.
  3. 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.
 

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.
     

Learn more about machine identity protection. Explore now.
 

Related posts

 

Like this blog? We think you will love this.
side image of a hand being held out to signal "stop"
Featured Blog

Android Implements TLS Encryption by Default

 

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Guest Blogger: Anastasios Arampatzis
Guest Blogger: Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat