What Is the Difference between Root Certificates and Intermediate Certificates?

What are certificate chains?

A certificate chain is a list of certificates (usually starting with an end-entity certificate) followed by one or more CA certificates (usually the last one being a self-signed certificate), with the following properties:

• The issuer of each certificate (except the last one) matches the subject of the next certificate in the list.
• Each certificate (except the last one) is supposed to be signed by the secret key corresponding to the next certificate in the chain (i.e. the signature of one certificate can be verified using the public key contained in the following certificate).
• The last certificate in the list is a trust anchor: a certificate that you trust because it was delivered to you by some trustworthy procedure. A trust anchor is a CA certificate (or more precisely, the public verification key of a CA) used by a relying party as the starting point for path validation.

In RFC 5280 the certificate chain or chain of trust is defined as “certification path”. In other words, the chain of trust refers to your SSL certificate and how it is linked back to a trusted Certificate Authority. In order for an SSL certificate to be trusted it has to be traceable back to the trust root it was signed off, meaning all certificates in the chain—server, intermediate, and root, need to be properly trusted. There are three parts to the chain of trust:

• Root Certificate. A root certificate is a digital certificate that belongs to the issuing Certificate Authority. It comes pre-downloaded in most browsers and is stored in what is called a “trust store.” The root certificates are closely guarded by CAs.
   
• Intermediate Certificate. Intermediate certificates branch off root certificates like branches of trees. They act as middle-men between the protected root certificates and the server certificates issued out to the public. There will always be at least one intermediate certificate in a chain, but there can be more than one.
   
• Server Certificate. The server certificate is the one issued to the specific domain the user is needing coverage for.
   

Certificate chains are used in order to check that the public key and other data contained in an end-entity certificate (the first certificate in the chain) effectively belong to its subject. In order to ascertain this, the signature on the end-target certificate is verified by using the public key contained in the following certificate, whose signature is verified using the next certificate, and so on until the last certificate in the chain is reached. As the last certificate is a trust anchor, successfully reaching it will prove that the end-entity certificate can be trusted.
 

Sponsorships Available

Sponsorships Available

Sponsorships Available

What are root certificates

The root certificate, often called a trusted root, is at the center of the trust model that secures Public Key Infrastructure (PKI).

Every device includes a so-called root store. A root store is a collection of pre-downloaded root certificates, along with their public keys, that reside on the device. Devices use either the root store built in to its operating system, or a third-party root store via an application like a web browser. The root stores are part of root programs, like the ones from Microsoft, Apple, Google and Mozilla. Microsoft users make use of the Microsoft root store, and so on.

The root programs run under extremely strict guidelines. In addition to the regulations and restrictions set 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. The strict requirements that CAs must adhere to, the audits, the public scrutiny are required to ensure that the CAs maintain enough social trust to merit the technical trust that comes with having a trusted root.

When a CA is being established, is not trusted a priori. For a given time, that CA does business through a cross-signed intermediate certificate, issued by an already trusted CA. A cross-certificate is a digital certificate issued by one CA that is used to sign the public key for the root certificate of another CA. Cross-certificates provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs. Once a CA has had its application accepted and proved itself trustworthy, then it gets its roots added to the root store.

A trusted root certificate is a special kind of X.509 digital certificate that can be used to issue other certificates. While any end user TLS/SSL certificates have a lifespan of maximum two years (soon to be 1 year), root certificates are valid for much longer. For instance, DigiCert’s (a trusted CA) root certificate is valid for 25 years.

In addition, every trusted CA has several root certificates, each with different attributes. This is visible in the root store.

In the above image, there are two root certificates issued by COMODO (now Sectigo) CA. One is for making RSA signatures and the other for ECDSA ones.

On a Windows OS, if you are looking at the certificate store, you would see all the Root CA certificates in the Trusted Root Certification Authorities. This by default includes the list of public root CA’s which are installed with Windows and are updated periodically through Windows Updates.

All certificates below root certificate put trust into the root certificate and the public key of root certificate is used to sign other certificates. Many software applications inherit the reliability of this root certificate like the browsers verify the SSL/TLS connections on the base of root certificate trustworthiness. Because of the value of these root certificates, and the risks that come with having one compromised, they are rarely used to issue end entity certificates. Instead we use intermediate certificates.

What are intermediate certificates

With the increase of PKI responsibility, the number of root CAs has been replicated. On the other hand it is not practical to have many Root CAs as it could lead to fraud and management issues. To resolve this problem, the concept of Intermediate certificate authority has been introduced. The Root Certificate authorities have delegated their tasks to Intermediate CAs. As a result, there can be more than one Intermediate CAs. An intermediate certificate works as a substitute of a root certificate because root certificate has its own security layers assuring that its keys remain unobtainable. Intermediate certificate plays a “Chain of Trust” between an end entity certificate and a root certificate.

This is how it works. The root 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 be repeated several times, where an intermediate root signs another intermediate and finally to sign an end entity certificate. These links, from root to intermediate to end entity, are the certificate chain.
 

What is the difference between root certificates and intermediate certificates

We can differentiate a root certificate from an intermediate one by looking at the certificate itself. If the Issued to and Issued by fields are same then it is a root certificate, otherwise it is an intermediate. Another identification would be to look at the Certification Path. The certification which appears at the top of the list is the root certificate. Below is one example of one of the public root CA’s:

In Windows environment, you may locate the intermediate certificates in the Intermediate Certification Authorities tab in local computer account console.

Implications of chained root systems

While there are many great security reasons for using chained root systems (as outlined above), there are also some challenges that you may have to face when using them:

• Increased complexity of installation
  When chained certificates are issued from an intermediate root, the intermediate root will have to be manually loaded on every web server and application that is hosting the certificate. This increases the complexity of installing chained root certificates and can lead to security risks if web servers are not compatible with chained root certificates.
• Betting the bank on the Stability of the Root
  Chained roots rely primarily on the trusted root anchor they are chained to, which means that intermediate certificates have no control over the root certificate. So, if the root CA is compromised or otherwise taken down, then all intermediate CAs associated with it would also fail.  
• No control over root expiration
  You need to choose carefully when you decide on a root certificate because when that certificate expires, all of your intermediate certificates will also be invalidated. So, you are basically at the mercy of the root certificate provider to manage the transition plan to a new root certificate before it expires. This process is extensive and can be a relatively arduous one for the root owner. as the new root must be embedded into future browsers, web servers, and applications that will use their certificates. And you may be exposed to a certain amount of that complexity throughout the process. So, you’ll want to choose a root certificate provider you can trust to be thorough and detail oriented.

All major Certificate Authorities use intermediate certificates because of the additional security level. 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 had signed, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.

Related posts

• The DarkMatter Debate: Why Organizations Need to Actively Protect Trust Stores
• Mozilla CA Quandary Highlights the Importance of Trust Store Security
• Serial Entropy Issues Invalidate 22,000 TLS Certificates on Dutch Government PKI
• Google, Apple, GoDaddy Mis-issue Over 1 Million Faulty Certificates

Public Key Infrastructure (PKI) supports a number of security-related services, including data confidentiality, data integrity, and end-entity authentication. Fundamentally, these services are based on the proper use of public/private key pairs. The public component of this key pair is issued in the form of a public key certificate and, in association with the appropriate algorithm(s), it may be used to verify a digital signature, encrypt data, or both.

A public key certificate is a signed statement that is used to establish an association between an identity and a public key. The entity that vouches for this association and signs the certificate is the issuer of the certificate and the identity whose public key is being vouched for is the subject of the certificate. In order to associate the identity and the public key, a chain of certificates is used. Certificate chain is also called certification path or chain of trust.