Welcome to the third and last installment of our “Networking Security” blog post series. If you didn’t read the previous ones yet, go ahead and read the first two parts:
- Part 1: What is TLS?
- Part 2: Verifying and Connecting
- Part 3: Trust and Certificate Chains
In this article we’ll talk about trust, and how it’s implemented thanks to certificate chains.
Chain of Trust
As explained in the previous posts, a server certificate can be signed by a CA certificate in order to confirm their identity. We trust that the CA has verified the contents of the server certificate before signing it, and hence we trust that the contents of the server certificate are valid.
Now, since a certificate that is used to sign other certificates, can in turn be signed by another certificate, we can build a whole “chain of trust”:
- At the top, there is the Root Certificate (also called the Anchor). It is signed by itself (self-signed).
- In between, there may be one or more Intermediate Certificates. They are signed by either other intermediates or the root certificate.
- On the bottom is our server (or client) certificate, called the Leaf Certificate.
In order to verify trust of a leaf certificate, we follow the “certificate chain” upwards until we reach a root certificate we already know and trust.
In order to know which root certificates to trust, we must have a “trust store” containing all the root certificates. This store is usually provided by the operating systems, but some clients (most notably web browsers) have their own “trust store”.
In order for a CA to have its root certificate accepted into the trust store of an operating system or browser, they must meet certain quality criterias. They must prove that they take CSR validation seriously and that they have measures put in place to keep their private key confidential.
Having their private key stolen by an attacker is the absolute worst-case scenario for any CA. It would mean that the attacker could create and sign ANY certificate using the CA’s cert! And since the CA’s certificate is trusted by all operating systems, clients connecting to the attacker would be none the wiser!
The only way to react to a compromised key is to rotate it, that is, to create a new one using a new private key. This however would mean that the certificate also has to be replaced in all trust stores. Since this can take a long time for some operating systems or clients, CA’s usually only use Intermediate Certificates to sign your certificates, and store the root key somewhere safe (and by safe I mean printed out on a piece of paper and stored in an actual safe.)
As explained, CA’s usually use an Intermediate Certificate to sign your CSR’s. An Intermediate Certificate, in turn, can be signed by either the Root Certificate or another Intermediate Certificate. This means that, in theory, there could be any number of intermediate certificates between your server (leaf) certificate and the Root. In practice, however, there is usually only one or two intermediates.
In order to verify a certificate, a client must possess the certificate that was used to sign it. So in order to verify the whole chain, it must have each intermediate certificate as well as the root certificate. The root certificate we already have in our trust store. But what about the intermediates?
When a CA has signed your CSR and sends you back the certificate, they will also send you all the intermediate certificates between your server cert and the Root. This is called the “CA bundle” or “CA chain”.
When we install our Server certificate in our web server, we also provide it the CA bundle. And when a client connects to the server, the server will send along the bundle with the certificate. This is safe because as long as one of the certificates in the chain is signed by a trusted root certificate, we know that we can trust the whole chain.
Note that the root certificate itself must NOT be part of the chain. It MUST come from the client’s trust store! Unfortunately some CA’s have the bad habit to include their root in the CA bundle, so make sure to remove it before configuring your webserver.
If you check your website against SSL Labs’ SSL Server Test, it will warn you if either intermediates are missing or the root (“anchor”) is included.
Congratulations, you’ve made it! You should now have some basic understanding about TLS/SSL certificates, what they do, and how they work!
Thanks to various browser vendors’ efforts, HTTPS has become the norm when surfing the web in recent years. And now that you’re armed with knowledge, there is no excuse anymore to serve your websites unencrypted!