The Difference in Root Certificates vs Intermediate Certificates (2024)

If you are in the process of getting an SSL certificate for your website, you will likely come across two terms – root certificates and intermediate certificates. It is only obvious to get confused between the two terms.

The key difference between root and intermediate certificates is that root certificates have their own trusted roots in major browsers’ trust stores. In contrast, intermediate certificate authorities issue certificates that rely on a root certificate, pointing back to a trusted third-party root authority.

Well, was this too much information to digest? Worry not. In this article, we will explain everything in detail. But let’s brush up on the basics first.

• How Does SSL Work?
• Why Is A Root Certificate Important?
• Why Are Intermediate Certificates Used?
• What Makes A Root Certificate Special?
• How To Know The Difference Between The Root Certificate And An Intermediate Certificate?
• More Implications Of The Chained Root System

SSL basically follows a private-public key pair implementation. Site data is encrypted based on a private key, and only viewers with the right public key can access the site. The public key is distributed to visitors in the form of a certificate file used every time a user tries to access a site.

If the site’s certificate is not valid, it means the site has not been properly verified and presents a potential threat. There are various certification levels that a site can take up, each with varying trust levels and validation processes.

Certificates are issued by proper certifying authorities, which conduct their own investigation as to whether the site applying for an SSL certificate is genuine or not. And each certificate has an expiry date, after which it is considered invalid and must be renewed to continue with the SSL protection features.

As you can see, SSL is a mechanism that allows the users to know whether the site they are connecting to has been properly validated by a certifying authority and is indeed the genuine site they want to access. Without SSL, there will be no encryption, and you also stand the risk of data breaches and security vulnerabilities.

You can consider digital signatures to be the piece of digital information that verifies a particular certificate file. It is similar to how we notarize physical documents with a qualified notary. In the SSL certificate chain, each component, be it a certificate or a public key, will be signed with a proper certificate.

When loaded by a browser, SSL sites will receive the certificates and the public key associated with the site. Once received, the browser app will verify the certificate’s authenticity with the help of the public key. It will check the digital signature of the certificate file and link to the certificate that signed it. This process of verifying digital signatures will continue until the final certificate in the certificate chain is reached.

The public key or the certificate issuing process consists of many security-related services that enforce the proper use of the public/private key pairs. There will be a chain of certificates used along the process that may not be accessible to the end-user. This certificate chain is also called the chain of trust or the certification path.

Each certificate chain has a list of certificates, including the final end-user certificate and one or more CA (certifying authority) certificates, and a self-signed certificate. Each certificate has the following properties:

• The details of the issuer of the certificate. This value will match the subject of the next certificate on the chain except for the last certificate in the chain.
• A secret key for the next certificate in the chain will be used to sign each certificate. Once again, the last certificate in the chain need not have this secret key signing process.
• The last certificate of a certificate chain, as mentioned earlier, differs from other certificates. It is called the trust anchor and is always delivered by a trustable entity such as a valid certifying authority (CA). It is generally coined as the CA certificate. Only a verified and highly trusted certifying authority can issue such root certificates as they are the trust anchors in a certificate chain.
  

Suppose a certificate chain cannot link back to a valid root certificate. In that case, it will be considered invalid, and the end-user application will not consider the corresponding website to be from a trusted source.

The certificate chain or the chain of trust defines the linking between your actual SSL certificates with the trusted CA. For any SSL certificate to be considered valid, it should trace back to a valid CA.

When you store the certificate of a new website you are trying to connect to, you can view the certificate for more details and get the certificate hierarchy. The first certificate you possess will be the root certificate, followed by intermediate CAs, and then the final certificate should point to a valid CA.

This is the certificate issued by the CA to the domain that needs to implement the SSL protocol.

As certificate chains are used to validate the end-user certificate to see if it is actually from a trusted CA, each certificate in a chain contains a digital signature that corresponds to the next certificate in the link, leading to the trust anchor certificate. Reaching the trust anchor certificate means that the end-user certificate can be trusted as it can be traced to a proper CA-issued trust anchor.

As you can see, the root certificate is the most important part of a trust chain as it is what is used to validate an end-user certificate. A root program helps manage the root certificates, and their public keys on the device in a particular location called the root store.

This root store location and implementation may differ based upon the device OS or any other third-party app used. Some of the popular root programs are provided by:

• Microsoft
• Apple
• Google
• Mozilla

While the actual implementation might vary among these root programs, they all follow some strict guidelines and regulations put down by the CA/B forum’s baseline requirements. Some root programs may also place additional restrictions to validate the certificate files.

A root certificate is the most critical part of the SSL protocol as any certificate signed with its private key information will be trusted by all browsers readily. Hence extra caution will be employed to make sure that a valid CA indeed issues the root certificate. It is the root certificate that establishes the trust factor that adds credibility to a site.

A valid CA has to undergo several verifications and compliance procedures to be deemed trustworthy enough to issue root certificates. So, it is through a root certificate that the trust anchor for a CA is established, which directly correlates to the sites that make use of the signed security certificates provided by the CA.

While the root certificate in itself is sufficient to implement the SSL security, in practice, most CAs make use of intermediate certificates. This is because of the practicalities involved in attaining the essential qualifications required to issue a CA.

In most general cases, a CA starts with issuing cross-certificates. These digital certificates are issued by one CA that links to a public key of a root certificate issued by another well-established CA.

A beginner certifying authority just starting its operations may not have the necessary qualifications to issue a root certificate yet. Hence, it will use another well-established CA’s services and link its certificates to a valid root certificate, thus forming the chain of trust. A single trusted root certificate will be linked to multiple other intermediate certificates with cross-certificates, thus allowing the users to get a valid trust chain for their SSL implementation.

Once the CA gets the necessary validation and is deemed trustworthy to issue its own root certificates, it will replace the trust anchor with its own root certificates. And the corresponding roots will be added to the root store.

Thus intermediate certificates serve to bridge the gap between an intermediate CA and a trusted root certificate. They are used to let growing CA companies find their footing and help establish a consumer base. Upon proper validation, they will issue their own root certificates completing the trust chain without another CA’s help.

Some more reasons why intermediate certificates are used are listed down below

• Intermediate certificates help control the number of root certificates in use and help mitigate security risks and fraud. As more and more users implement SSL sites, the number of root CAs will also increase. But having too many root CAs can lead to serious security implications, which intermediate certificates aim to resolve. They provide a means for the root CAs to delegate some of the certificate issuing responsibilities to intermediate CAs, providing intermediate certificates that will substitute for a root certificate.
• Intermediate certificates can be replicated in high numbers without compromising the security framework and helping establish the Chain of trust.
• They help with the scalable implementation of the SSL network.

Almost all trusted CAs use intermediate certificates as it adds an additional layer of security and helps manage security incidents gracefully. In case of a security attack, only the intermediate certificate needs to be revoked instead of revoking the root certificate and all associated certificates it has been used to sign.

By revoking just the intermediate certificate in question, only the group of certificates that are in the same chain as the intermediate certificate will be affected, thus minimizing the cost and impact of the security incident.

A trust anchor or the root certificate is a special type of SSL certificate of the format X.509. It can exist by itself or can also be used to issue other intermediate certificates. Here are some more characteristics of a root CA that make it special.

• The lifetime of a root CA is much longer than a regular TLS/SSL certificate. It can be as high as 25 years compared to the usual 1- or 2-year limited lifespan of a regular certificate.
• Each trusted CA may have various root certificates, each differing in its attributes, such as the digital signature used. The certificate properties can be viewed from the root store applications.
• It is through the root certificate that a public key is signed and other certificates are validated. If an intermediate certificate chain link does not trace back to a root certificate, it will be considered invalid.

A CA authorized to issue root certificates must follow strict compliance and rules to achieve the status that lets them issue root certificates. A root CA must qualify under two specific contexts to be authorized to issue root certificates.

Social trust

• Social trust refers to the various audits, rules, regulations, and public scrutiny that the CA must undergo to be deemed trustable. It can also apply to the CA’s branding and image perception in the market.

Technical trust

• Technical trust refers to how technically strong and secure the root CA is with regards to its certificate implementations and security measures. Only a technically strong CA will be able to garner the social trust required to function in the long term.

Finding whether a certificate is root or intermediate is quite easy and can be directly inferred by looking at the details from the root store. Here is how you can know the details of a certificate.

Click on the certificate from the root store and open it to view its details.

Go to the Certificate Verification Path. You will be able to see the various levels in the certificate path. You can also collect further details like the CA that issued the certificate, the CA to which the certificate is issued, and the certificate’s lifespan.

Here are the markers that show that a certificate is a root certificate.

• The certificate path contains just one level.
• The issued to and issued by values point to the same CA.
• The certificate has a valid lifespan of more than two years. The validity of a root certificate is usually up to 25 years, whereas intermediate CAs have just about one or two years of validity.

The Windows root store application makes it easier to differentiate between the certificates as it lists down them in different categories. You can find the root certificates in the Trusted Root Certification Authorities and the intermediate certificates under the Intermediate Certification Authorities.

Although the chained root implementation is the most commonly used, it also presents certain implementation complications.

• Installation of Chained root can be a complex process as the intermediate certificates will have to be loaded to every server and app that uses a certificate in the chain.
• Chained roots are heavily reliant on the trust anchor they are chained to. Intermediate certificates have no control over the root certificate. If the root CA were to go out of business, the reliant intermediate CAs would also have to go down along with it.
• Another complication in the implementation of intermediate certificates is the lifetime of the certificates. In general, root certificates have a comparatively much longer lifespan of 25 years. And intermediate certificates must always have their expiry date set lower than that of their trust anchor. This can add to the complexity of the installation as if a root certificate is nearing its expiration date, all of its intermediate certificates must be made to expire before that date.

Undoubtedly, managing certificates and understanding all the technicalities involved is challenging. Not anymore. Entrust Keyfactor for all your needs related to security certificates, and relax! Contact us to learn more today.