March 25, 2021 0

What Is an SSL Certificate Chain & How Does It Work?

in Web Security

(29 votes, average: 3.76 out of 5)

Loading...

The SSL certificate chain consists of multiple certificates and helps to establish trust with browsers and clients. Here’s what to know about these chain certificates and how the “chain of trust” works.

As a website owner, you know that an SSL/TLS certificate is a must for having a successful online business. In addition to increasing trust and securing data, it also helps to boost your site’s ranking in the eyes of Google. But an SSL certificate doesn’t operate in a bubble; it’s part of something known as an SSL certificate chain. This chain is integral to the larger public key infrastructure that makes secure online communications possible over the insecure internet.

But what exactly is the certificate chain and why is it so important to establishing trust? We’ll break down the different components of the chain, what their rules are, and how they work together as part of the larger public key infrastructure.

What Is an SSL Certificate Chain?

So, what is the certificate chain for SSL and TLS? The chain of certificates includes a root certificate, one or more intermediate certificates, and the server (leaf) certificate. If you don’t know what some of these are, no worries. That’s what we’re here for — to help break down these terms in a way that makes sense. 

You’re likely already familiar with the server certificate if you came here because that’s the certificate you purchase for your website. It’s what makes the padlock icon appear in the web address bar before your domain and what makes “HTTPS” appear in your URL.

If you click on the padlock of a secure site, you’ll see the details of the SSL certificate. The screenshot attached below will give you an idea about what you will see. For example, here on SectigoStore.com, you’ll see the name of the organization that the certificate was issued to. In this case, it’s Rapid Web Services LLC, [US].

This is what we typically mean when we talk about SSL/TLS certificates. The other two types of certificates in the chain are what help to establish trust for those server certificates.

SSL certificates are issued by a reputable and trusted third party known as a certificate authority, certification authority, or CA (for short). However, the CA does not issue the certificates directly to the websites. There’s a chain of trust, or a chain of certificates, that makes the process faster and easier.

The Chain of Trust is Like a Tree…

To understand how these certificates work together, imagine a tree. A tree has roots, a trunk and its corresponding branches, and the leaves. A certificate chain is not that different from a tree in terms of its structure.

As with a tree, the root certificate is the foundation upon which all other certificates are based. And just like how a tree has many branches, there can be more than one intermediate certificate that a CA issues from a single root certificate. The same analogy applies to the leaves that represent the server certificates.

If we continue to explore the SSL certificate for this site, we’ll learn a lot. So, click on the Certificate option and you will see a window pop up like the one in the image below:

This image shows you the certificate’s information — such as its purpose, who (which CA) issued it, the site to which it’s issued, and its validity date.

A step further will take you to the certificate’s details, which will help you know the protocol and the algorithms this certificate uses. It shows you the algorithm with which the public key is encrypted and also provides the site’s public key.         

Now, we come to the next part, which is the certificate path. This is the most important part of the certificate information article in the context of this article. When you click on the “Certification Path,” you’ll see the root, intermediate, and server certificates.

In the above image we can see that:

• The root certificate is “Sectigo (formerly Comodo CA).” This is a self-signed certificate that signs the intermediate CA certificates.
• The intermediate certificate is “COMODO RSA Extended Validation Secure Server CA.” This certificate serves as an intermediary — a go-between — for the root and server certificates to put some distance between them. So, the intermediate certificate signs the server certificates using its own private key to protect the root certificate’s private key.
• The server certificate is “www.sectigostore.com”. This is the type of certificate that you install on your website’s server that’s commonly known as an SSL/TLS certificate.

Since the leaf certificate branches from the intermediate, and the intermediate from the root, imagine that the tree you pictured earlier is upside down. In the screenshot above, basically, the roots of the tree are at the top and the leaves are on the bottom.

Understanding the Various Parts of the SSL Certificate Chain

The SSL certificate chain and the details on the signing authorities can be explained in the figure below:

In this section, we’ll break down not only the differences between root certificates and intermediate certificates but also server certificates as well.

Root Certificate

A root certificate, also known as the trusted root, is the certificate issued directly by the certificate authority. Unlike the other certificates, the root certificate is self-signed by the CA. The private key of the root certificate is what’s used to sign the other certificates in the hierarchy of the SSL certificates.

A CA only issues a handful of root certificates, which is why they’re so heavily guarded. In fact, these root certificates are typically pre-loaded in the “trust stores” of browsers and operating systems. The root certificate is considered most important in the certificate chain because all the parties agree to trust the CA issuing the root certificate. The whole chain will break down if the CA issuing the root certificate is distrusted or revoked (i.e., no longer considered trustworthy).

To protect these certificates, particularly in cases involving certificate revocations, root CAs often use intermediate CAs to put some space between their trusted root certificates and the end server certificates. They never issue leaf (server) certificates from websites directly from their root certificate because it’s too risky.

Intermediate Certificate

The intermediate certificate serves as a buffer between the root certificate and the end entity’s server certificate. It’s signed by the private key of the root certificate that issues it. This is how trust of the intermediate certificate is established. The intermediate certificate issuer is the one who signs the SSL/TLS (server) certificate, whereas the subject is the site or organization whose identity is vouched for.

There can be more than one intermediate certificate, but you cannot have a certificate chain without at least one intermediate certificate.

Server Certificate

A CA issues the server certificate, also known as a leaf certificate, to the domain that the user wants to cover. This is what people are talking about when they refer to SSL/TLS certificates. When you install this certificate on your server correctly, then you’ll see “HTTPS” instead of “HTTP” at the start of your URL. The HTTPS indicates that your site is using a secure, encrypted protocol instead of an insecure one. Also, a padlock will appear before your domain name in the web address bar.

How Does the Certificate Chain Work?

The chain of certificates in SSL/TLS is also known as a chain of trust. The reason behind this is when any browser receives the SSL certificate for your website, it needs to verify that it’s legitimate.

To do this, it will start with the server certificate and follow it back to the root certificate to establish the trust. It uses the certificate’s public key to match the signature before moving back to check the intermediate certificate’s public key and signature in the same way. It’ll keep doing this until, eventually, it reaches the root certificate that the browser keeps in its trust store.

If any of the certificates in this chain cannot be verified, the chain will be broken and the validation will fail. The browser will issue a warning about the certificate to the user. You know those ugly “not secure” and “Your connection is not private” messages?

Yeah, like that. Thus, for the chain of trust to work, it’s is imperative that no link in this chain is broken.

Are you still with me? Then I can take a step further and explain to you how the chain of certificates works. After that, we can talk about the technology and processes working behind the scenes — public key infrastructure (or what’s also known as PKI).

How the Chain of Trust Verification Process Works

If a conventional hierarchy is followed, the root CA authenticates an intermediate CA, which, in turn, signs the server certificate. So, with that in mind, how does one use the chain of trust for verification?

When a user visits your website, your server sends them its certificate. It will check a variety of information, such as:

• What entity issued the certificate and to whom it was issued.
• When it was issued and how long it’s valid for.
• If it has a valid digital signature.
• Whether the certificate has been revoked.

To verify the certificate is legitimate, it needs to validate the chain of trust. Here, the browser will start from the server certificate and validate all the certificates including the root certificate. The most common certificate chain validation process moves in reverse. This means starting with checking the server certificate’s information against the intermediate certificate that issued it before moving on to check the intermediate certificate against the root certificate that issued it.

If all the certificates check out, and once the other processes required for a secure connection are finished, the website will load with a padlock symbol or “HTTPS” in the URL bar. If not, a warning will be issued.

What Is PKI?

Because PKI is such a complex and detailed topic, we’re just going to give you a quick overview here. Public key infrastructure is a catch-all term that describes the framework of processes, policies, and technologies that make secure encryption in public channels possible. It relies on public key cryptography, which uses complex mathematical algorithms to facilitate the encryption and decryption of messages over the internet.

These algorithms are integral components of the PKI framework. The algorithms have become more complex over time as technology has developed.

PKI uses key pairs to encrypt and decrypt data. And the types of keys involved depends on the type of encryption you use. For example, symmetric encryption uses a single key to both encrypt and decrypt data. (This requires the sender and recipient to have identical copies of the same key.) In asymmetric encryption, on the other hand, there are two unique (but mathematically related) keys: a public key and a private key. The public key, which is available to anyone, encrypts data. The private key, on the other hand, decrypts data and must be protected to keep it safe from compromise.

Having two unique yet mathematically related keys helps the site visitor’s client pass on secure messages without the fear of unauthorized access or data manipulation. (What’s commonly known as a man-in-the-middle attack, or MitM.)

Conclusion

The SSL/TLS certificate ensures the safety and security of your website through the use of the secure HTTPS protocol. The chain of trust is crucial for the implementation of this security protocol. Due to the tree-like structure of the chain of certificates, it is possible to establish contact with the server quickly and securely. And it makes it easy to trace the certificate back to its original root to know if it’s legitimate. This is a win-win all the way around for everyone.  

• #chain of trust
• #SSL certificate chain