(13 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• Google +
• LinkedIn
• Mail

August 28, 2018 12

The Difference Between Root Certificates and Intermediate Certificates

in Everything Encryption

Many people don’t realize that an end user SSL certificate is only one part of a certificate chain.

Let’s talk about intermediate and root CA certificates for a few minutes. SSL (or more accurately, TLS) is a technology that most end users know little to nothing about. Even the people acquiring it typically don’t know much beyond the fact they need an SSL certificate, and they have to install it on their server to serve their website via HTTPS.

That’s why when you start mentioning Intermediate certificates and CAs and Root certificates and CAs most people’s eyes start to glaze over, which makes it a topic you should probably stay away from on a first date (certificate chains are more of a fourth or fifth date conversation).

But given that SSL is kind of our thing, and because we get asked a lot of questions about them, today we’re going to delve into certificate chains, intermediates and roots. It may seem like a lot at first, but hopefully by the end of this article it will seem pretty straightforward.

So without further ado, let’s hash it out.

What is a Root Certificate?

A root certificate, often called a trusted root, is at the center of the trust model that undergirds SSL/TLS. Every browser includes a root store. Some browsers run their own, while others make use of a third-party store. A root store is a collection of pre-downloaded root certificates that live on your device. A root certificate is invaluable, because any certificate signed with its private key will be automatically trusted by the browsers.

Trusted roots belong to Certificate Authorities—the organizations that validate and issue SSL certificates. We’ll delve into that a little bit deeper in a few moments, but first let’s discuss certificate chaining.

What is the certificate chain?

Before we can  go any further, we need to introduce the concept of the certificate chain. Let me start by posing a question: how does your browser know to trust a website’s SSL certificate? When you arrive at a website, your browser takes a look at its SSL certificate and performs a quick process to verify the certificate’s authenticity.

What your browser is doing to authenticate the certificate is following the certificate chain. So, what is the certificate chain then? To get an SSL certificate issued you start by generating a Certificate Signing Request (CSR) and a Private Key. In its simplest iteration, you send the CSR to the certificate authority, it then signs your SSL certificate with the private key from its root and sends it back.

Now, when a browser sees the SSL certificate, it sees that the certificate was signed by one of the trusted roots (or more accurately, signed with the root’s private key). Since it trusts the root, it trusts any certificate the root signs. In this example, the server certificate chains directly to the root.

What is an intermediate certificate?

Certificate Authorities do not issue server certificates (end user SSL certificates) directly off of their roots. That would be dangerous, because if there’s ever any mis-issuance or mistake that requires the root to be revoked every certificate that was signed using the root would be distrusted immediately.

So to insulate themselves, CAs generally issue what is called an intermediate root. The CA signs the intermediate root with its private key, which makes it trusted. Then the CA uses the intermediate certificate’s private key to sign end user SSL certificates. This process can play out several times, where an intermediate root signs another intermediate and then a CA uses that to sign certificate.

Here’s a visualization of a certificate chain. For our example we’re only going to use one intermediate to keep it simple. Real-world certificate chains are often far more complicated.

What role does the digital signature play?

A digital signature is kind of like a digital form of notarization in this context. When a root certificate digitally signs an intermediate certificate it is essentially transferring some of its trust to the intermediate. Because the signature comes directly from the trusted root certificate’s private key, it’s automatically trusted.

This paragraph will get a little technical, so feel free to skip ahead. Anytime a browser or device is presented with an SSL certificate it receives the certificate itself as well as the public key associated with the certificate. Using the public key, it decrypts the digital signature and sees who it was made by–what certificate signed it. You can probably start piecing this together now. When your browser is authenticating the end user SSL certificate on a website, it uses the public key that is provided to decrypt the signature and move one link up the chain. It continues repeating this process – decrypting the signature and following the chain to the certificate that signed it – until eventually it arrives at one of the root certificates in the browser’s trust store.

If it can’t chain the certificate back to one of its trusted roots, it won’t trust that certificate.

Ok, so what is the difference between a Root CA and an Intermediate CA?

This is actually fairly straightforward. A Root CA is a Certificate Authority that owns one or more trusted roots. That means that they have roots in the trust stores of the major browsers. Intermediate CAs or Sub CAs are Certificate Authorities that issue off an intermediate root. They do not have roots in the browser’s trust stores, instead their intermediate roots chain back to a trusted third-party root. This is sometimes called cross-signing.

Now, here’s where it can get a little confusing. As we discussed earlier, CAs do not issue directly from their roots. They add layers of security by issuing intermediates and then signing certificates with those. This helps to minimize and compartmentalize damage in the event of a mis-issuance or security event. Rather than revoke the root certificate and literally every certificate that it signed by extension, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.

Here’s a practical example, Google and the other browsers recently distrusted Symantec CA brand SSL certificates. At first blush that might seem like a monumental task, distrusting millions of end-user SSL certificates. In reality, it was very simple. They just removed all of Symantec CA’s roots from their trust stores. Now any certificate that is supposed to chain back to those roots fails and is distrusted. (It’s worth noting that DigiCert has cleaned up Symantec nicely, but this serves as a good real life example for this discussion.)

What’s the difference between a chained root and a single root?

That actually hearkens back to our last question. A single root is possessed by a CA. It can issue certificate directly, making it much simpler to deploy certificates and simplifying installation. A chained root is what a Sub CA uses to issue certificates. It’s an intermediate certificate, but, because the Sub CA doesn’t have its own trusted root is has to chain to a third-party CA that does have one.

This makes a difference, too. Here’s why:

• Chained roots make for more complicated installations because the intermediate root will need to be loaded on to every server and application that hosts the certificate.
• Chained roots are at the mercy of the CA they are chained to. They have no control over the root, so if the Root CA goes out of business they’re screwed.
• Roots and Intermediate certificates expire, too. Albeit on longer timelines. Still, an intermediate must expire before its root, which adds complexity.

A final word on Roots and Intermediates

What we’ve just described – the trust model involving Certificate Authorities, certificate chains and cryptographic signatures – is essentially PKI or Public Key Infrastructure. I’ve avoided using that term until now because it seems very abstract until you drill down into the specifics a little bit.

But, when someone refers to PKI this is what they mean. And with that in mind, you can probably work out how a Private CA and self-signed certificates are deployed in an Enterprise context. Working alongside a trusted CA, an organization generates a root certificate(s) and private key (this is called a key ceremony). The organization then adds the root to its own root stores, across all its systems and devices. And from that point, the organization can self-sign its own X.509 certificates using the private key from its own roots and they will be trusted across its network.

Frankly, that’s the future of PKI. And the future is arriving faster than anyone realizes.

• #Certificate Chain
• #Intermediate Certificates
• #Root Certificates