The Difference Between Root Certificates and Intermediate Certificates 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.