• Facebook
• Twitter
• Google +
• LinkedIn
• Mail

June 26, 2019 42

The Difference Between Root Certificates and Intermediate Certificates

in Everything Encryption

That 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 Program?

The root certificate, often called a trusted root, is at the center of the trust model that undergirds Public Key Infrastructure, and by extension SSL/TLS. Let’s start by discussing root programs and work our way out from there.

Every device includes something called a root store. A root store is a collection of pre-downloaded root certificates (and their public keys) that live on the device itself. Generally, the device will use whatever root store is native to its OS, otherwise it might use a third-party root store via an app like a web browser. There are several major root programs of note:

• Microsoft
• Apple
• Google
• Mozilla

Apple users, both macOS and iOS, rely on the Apple root store, likewise for Microsoft users and its root store. Android uses Google’s. And the Mozilla suite of products uses its own proprietary root store.

The root programs run under extremely strict guidelines. In addition to the regulations and restrictions put forth by the CA/B Forum’s Baseline Requirements, some root programs – for instance, Mozilla’s – add even more stringent requirements on top.

The reason for this is simple: trust.

A root certificate is invaluable, because any certificate signed with its private key will be automatically trusted by the browsers. Ergo, you really need to make sure you can trust the Certificate Authority issuing from it.

In this sense it might be helpful to view trust in two specific contexts:

• Social Trust
• Technical Trust

The latter is entirely contingent upon the former. The strict requirements that CAs must adhere to, the audits, the public scrutiny – it’s all meant to ensure that the CAs maintain enough social trust to merit the technical trust that comes with having a trusted root.

Generally, these things are pretty straightforward, usually a CA has already been issuing off a cross-signed intermediate (we’ll get to that in a second) and conducting its own CA business for a period before applying to have its root trusted. Or, put another way, you can’t just form a CA and immediately apply to have your root trusted. And the deliberations can at times skew political, as we saw with the debate of the DarkMatter CA a few months ago.

Regardless, once a CA has had its application accepted and proved itself trustworthy, it gets its roots added to the root store.

What is a trusted root certificate?

As we just covered, a root certificate is a special kind of X.509 digital certificate that can be used to issue other certificates.

For starters, whereas end user or leaf SSL certificates (and generally any kind of publicly trusted PKI certificate) have a lifespan of two years – tops – root certificates live much, much longer. Here’s one of DigiCert’s EV roots, take a look at the its validity period:

Now, as you’ve likely inferred by now, each CA has more than one root. In fact, most CAs have several. Here’s a quick look at the root store on my computer:

Generally different roots will have different attributes. This is probably best illustrated by the two COMODO (now Sectigo) roots near the top of that list. One for making RSA signatures and the other for ECDSA ones.

Any certificate that is issued off any of these roots will automatically be trusted by my computer system. Now, so far we’re looked at this in an overly simplistic way. The value of these roots, and the risks that come with having one compromised, mean that they’re rarely actually ever used to issue certificates. Instead the spin up and issue off of intermediates, but before first…

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? We’ve covered that any certificate descendant of a trusted root is, by extension, trusted. But how does that work on a technical level?

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. It checks its validity dates, ensures the certificate hasn’t been revoked and it authenticates the certificate’s digital signature.

What your browser is doing to authenticate the certificate is following the certificate chain. 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 issued by one of the trusted roots in its root store (or more accurately, signed with the root’s private key). Since it trusts the root, it trusts any certificate the root signs.

Again, this is oversimplified to make it easier to understand. In this example, the server certificate chains directly to the root. Now let’s mix in intermediates.

What is an intermediate certificate?

As stated above, Certificate Authorities do not issue server/leaf certificates (end user SSL certificates) directly off of their roots. Those roots are too valuable and there’s just too much risk.

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 and issue 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. These links, from root to intermediate to leaf – are the certificate chain.

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.

You may have noticed that sometimes when your CA issues an SSL certificate that it will also send an intermediate certificate that you’ll need to install, too. That’s so that browsers will be able to complete the certificate chain and link the SSL certificate on your server back to one of its roots.

Browsers and operating systems vary on how they treat an incomplete chain. Some will just issue and error when an intermediate is missing, others will save and cache intermediates in case they may come in handy later.

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 verifies 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 verify the signature and move one link up the chain. It continues repeating this process – authenticating 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 too much 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.

As always, leave any comments or questions below…

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