The Difference Between Root Certificates and Intermediate Certificates
1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 3.50 out of 5)

The Difference Between Root Certificates and Intermediate Certificates

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.

difference between root and intermediate certificate

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.

difference between root and intermediate certificate

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.

difference between root and intermediate certificate

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…

Hashed Out by The SSL Store is the voice of record in the SSL/TLS industry.
  • This is the first online document on certificates and trust chains that read through without glazing over. Well written ; good schematic and excellent quality material.
    Thank you for publishing this.

  • you write
    “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. ”

    this would indicate there is a checking of the root CA validity. because the root CAs are pre-downloaded, is there such a thing as periodic updates or is it actually static ?

  • @MI. That’s a valid question. His statement is theoretical. In the real world as he pointed out in the Symantec CA example, one would need to remove it from their root store which most people don’t, so Google does the clean up with their Chrome 70 update. So yes it’s static.

  • Maybe stupid question, but what prevents the end ssl certificate to sign malicious certificate? It would go up the chain till the trusted root one.

    • Because an end certificate is set to not allow ongoing signing, if you use openssl for certificate creation for instance the extended key usage is set to CA:FALSE aka this certificate can not sign anything “under” it, most subCA / CA will have CA:TRUE along with other key extensions (which will only confuse more at this point) but thus allowing them to sign other sub certificates normally the server certs

  • will Connection fail if the server send only server certificate not the intermediate and root when there is not inter and root on the trusted store in the browser?

  • Awesome explanation. The SSL certificate chain is a very hard concept to understand but this article explains it very nicely.
    I have a question, can server use only root certificate to validate its identity? The certificate packet from server having only root certificate is a valid scenario?

  • Hi,
    I already have Root CA install on my server, then on client i have intermediate CA installed.
    Now the certificate is coming to an end, if i renew the certificate should i re-install the intermediate CA on the client side?

    • It depends on your renewal decision, if you stick with the same certificate you should be fine with the intermediate you already have. If you switch CAs or change certificates you may need to install a new one. The CA will include any intermediates you need to install in your certificate bundle.

      • currently we are using LDAP but now SA is forcing to use LDAPS and provided two updated certificate namely root CA and intermidate CA i have installed them using mmc on windows server 2012, but application is unable to connect LDAPS
        sa says change ssl certificate on iis, how can i generate new ssl using this two certificate ??

  • Ok so if love for you to get deeper into it, I’m pretty sure I know most of what you haven’t mentioned, for instance that these certificates control security of all the internet and are what controls or can create havok cyberwise and is extremely important in keeping and securing government information and even military and aerospace operations, not to mention drug task force and secret service missions that are meant to be kept just that, secret. These certificates have alot of control in the future and are of at high importance in keeping and securing governments from even possibly receiving attacks from countries that can cause catastrophes cyberly and can create war. Attacks on our internet servers for example, Telecom. Good example, spying on governments. This stuff is not only intriguing to me but I believe has become to me something I see in the near future that could lead to the end of mankind one day. I have much respect for the people that work on these, and I hope one day I can follow my passion on this and do my part to help keep people and the world a safer place. Sorry but I’ve become much of an obsessed nerd on this subject. Cyber security and technology is growing so fiercely it’s almost scary. So please, teach me some deep stuff so that I can know if I am right and can feel better knowing that these groups of security specialists are making progress in attacks like Telecom. I look forward to hearing your information. Thank you.

  • Excellent, thanks a lot!
    Though the “Symantec CA brand SSL certificates” example left me a bit confused.
    Symantec CA brand SSL certificates were root CAs and not Intermediate certificates, right?
    So Symantec CA brand SSL certificates case cannot serve as an example for how compromised intermediate certificate is easier to deal with compared to compromised root CA.
    I apologize in advance if I misunderstood something.

  • This is one of the best certificate chains explanation I’ve ever seen.
    Clear and understandable.

    Congrats !

  • excellent write up.
    Working with corporate internal PKI’s I am used to store intermediates also in truststores of applications as work around for connections to servers with incomplete certificate chains. BTW the command ‘openssl s_client -connect -showcerts’ is handy to check certificates and certificate chains on tls enabled connections.

  • This is a good discussion of chained trust and trusted root certificate authorities. One item I feel neglected is the question of trusting the foreign root CAs. It is fairly simple to remove a root CA certificate from an operating system or browser using just the built-in tools. Doing so reduces the trust that OS or browser has which may block interactions based upon the security policy (settings) of that OS/browser. Removing foreign root CAs is the opposite of adding private “root” CAs to the digital devices you control

  • This article violates the most basic rules of good documentation from the get-go. It mentions the concept vaguely of “root certificate” and delays giving any kind of definition or more importantly, discussion of the problem a “root certificate” is supposed to solve. Okay, we wait with baited breath. Then the article does a head-fake that gives us hope of some clarity with a good headline “What is a Root Program?”. However it then fails to define a Root Program or discuss the problem a Root Program is supposed to solve and instead begins rambling on with anecdotal statements related to the mysterious “Root Program” such as: all devices have a “root store” (whatever that is), followed by a list of notable Root Programs (still undefined and mysterious), and some statements of proprietary “root stores” (maybe root stores and root programs are related in some way, who knows? Their names seem suggestive…), followed by the fact that these as yet mythical Root Programs “run under strict guidelines” (why should I care? I don’t know what it is or what it does). Then there is some talk about “trust” and certificates, assuming we know what a “certificate” is or what it might be used for — if I knew that, I probably wouldn’t need to read the article. Well, I could go on. I’m sure if you read the article to the end, then go back, reread it a few more times then read some related articles it all makes sense. IMHO, this is not good didactic writing because it avoids both top-down defining of terms or bottom-up analogies that would help you build understanding. Instead it is a rambling discourse of puzzle pieces that with effort can be assembled into a concept if you work at it hard enough. However, combined with other similar puzzle-docs, we can probably get where we need to go, just not as efficiently as we should.

  • What happens when certificates fail and information out of date . Wrong certificate information how to clear cerficate

  • man you could have explained the intermediate certificate part better. you say “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” should have been explained more if you really understand this, does it mean the entire chain is sent in the handshake, except the root certificate, which the browser or device should already have? Explain more the critical part, no one’s eye are glazing over here, explain clearly or do not write articles.

  • Hi There,

    When deploy a certs with Root CA- Intermediate CA- and End User Certificate..

    When we use the certs, is it mandatory that Intermediate CA and Root CA are connected all the way along..

    e,g. can we use Intermediate CA only for isolated systems?


Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *


Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.