What is the SSL Certificate Chain? Explained by a Certificate Authority

A look at the SSL certificate chain order and the role it plays in the trust model

There are tons of different kinds of chains: gold chains, bike chains, evolutionary chains, chain wallets… Today we’re going to discuss the least interesting of those chains: the SSL certificate chain.

Public key infrastructure (PKI) is a hierarchy of trust that uses digital certificates to authenticate entities. There are myriad uses for PKI — everything from digital signatures to encrypted internet connections. One thing all of them share in common is they use a certificate chain to establish identity.

How to Get an SSL Certificate Chain

When you arrive at a website, the serving hosting sends a copy of its SSL certificate to your browser as part of what’s known as a “handshake.” The handshake process is where authentication occurs and the parameters of a secure, encrypted HTTPS connection are negotiated. To authenticate the server, your browser will perform a series of checks on the certificate its presented. It will check certificate transparency (CT) logs, online certificate status protocol (OCSP) servers, revocation lists, and the digital signature on the certificate itself.

This last part, verifying the digital signature, is where the certificate chain comes in.

Starting at the Bottom – With the Roots

Certificate authorities (CAs) are the organizations responsible for issuing trusted digital certificates. They’re strictly monitored and must comply with stringent standards to ensure they maintain their trusted status. The return for this is that their issuing root certificates get included in the major root stores run by the various OSs and browsers.

How to Validate the SSL Certificate Chain

When a certificate is issued, the CA performs a validation of the entity requesting the certificate. Once that’s satisfied, it issues a certificate that includes the validated information and signs it with the issuing certificate’s private key.

This digital signature can be verified using the same certificate’s public key.

It all starts with the root certificate. These are incredibly powerful, long-lived digital certificates that can be used to issue other trusted certificates. This is all done with digital signatures.

But CAs don’t issue directly off their root certificates. That would be too dangerous and also raises a laundry list of technical issues. Instead, to protect the root certificates, the CAs spin up and sign intermediate roots. Whereas the root certificates themselves reside in root stores and physically live on the devices that use those root stores, the intermediate roots do not. This is why it’s oftentimes necessary to install an intermediate alongside your end user or leaf SSL certificate.

The SSL Certificate Chain Order

This will all make more sense when we put it together.

1. A CA undergoes the requisite vetting to be trusted and have its issuing roots included in the various root programs.
2. The CA uses its root certificates to issue and sign intermediate root certificates.
3. The CA uses those intermediates to issue end-user/leaf (server) SSL certificates.

Here’s an SSL certificate chain example from RapidSSLonline.com:

Following the SSL Certificate Chain

Now, let’s talk about the actual trust model that leverages the SSL certificate chain. Remember earlier when we talked about how the browser receives the server’s SSL certificate during the handshake? Well, in addition to the leaf certificate, it also receives any associated intermediates. These intermediates are needed to complete the chain. Oftentimes, modern browsers will cache intermediates in case the server doesn’t have all the right certificates installed, but if you’re a site owner, it’s always best to ensure you have the completed certificate chain at your users’ disposal.

When the user receives the certificate, it checks the digital signature. So, in the case of the leaf certificate, it checks the signature that was left by the intermediate root that issued it. That intermediate should also be installed, and its public key comes included, so the browser uses its public key to verify the signature on the leaf certificate.

Provided that checks out, it moves to the digital certificate that was affixed to the intermediate by whatever certificate issued it. This could be one of the roots in its trust store, or another intermediate. Regardless, it takes the signing certificate’s public key and verifies the signature on the previous certificate. It continues to do this until it reaches one of the roots in its root store.

Wrapping This Up

If you can chain the signatures back to the root, it means that the end user certificate is descendant of that root. That root is trusted, so anything it signs is trusted.

Long story short — as long as a certificate can be chained back to one of the roots in a device’s root store, that device will trust it. If it can’t be chained back to the root, your browser will issue a warning about the certificate.

Which more than you can say for anybody with a chain wallet.