Root Certificates – Root vs Intermediate Certificates

Public Key Infrastructures, or PKIs, are becoming many organizations security backbone, as they provide authentication and identification to the devices, individuals, or applications working within a company’s network. The way a PKI works, is a device, user, or application that wishes to work in an organization’s network sends out a Certificate Signing Request (CSR), which contains their public key, and the information needed to create a certificate for that user. The public key is part of a key pair created by the requestor, which is made up of a private and public key. The private key is kept secret from everyone, while the public key is used to match messages, certificates, or other communications signed by the private key to the corresponding public key. The CSR is sent to an Issuing Certificate Authority, or CA, which is in charge of issuing and managing certificates. Once the request, is accepted, the certificate is sent to the requestor.

Figure 1: A diagram of how a CSR works

These certificates contain information about the certificate owner, including the Issuing CA’s name, the Certification Path, the requestor’s public key, and much more. Certificates share the identity of the certificate owner with other devices, applications, and users on the network, so that they know that the certificate owner can be trusted. This trust is ascertained via the Certification Path, or Certificate Chain of Trust, of the certificate issued to the certificate owner.

Understanding the Chain of Trust

As mentioned previously, part of a certificate is the Certification Path, or Chain of Trust, of the certificate. This Chain of Trust is a path linking the certificate owner’s certificate back to the Root CA’s certificate. The reason for a Chain of Trust is to give the inquiring service or user trust in the certificate whose chain they are following. When a web browser connects you to a website, the first thing they do is check that website’s certificate. If the certificate used by the website is found to be valid, the web browser then checks the Chain of Trust of the certificate. Though the certificate is still valid, the browser must verify the Intermediate, Issuing, and Root CAs’ certificates as well.

Figure 2: An example of a certificate

The below image is an example of what a Chain of Trust looks like. The certificate at the bottom named *.encryptionconsulting.com is this website’s certificate. The certificate named R3 is the Intermediate certificate, and the certificate named DST Root CA X3 is the Root certificate. Several components are checked on each of these certificates:

1. The issuer of the currently viewed certificate must match the previous certificate’s name in the chain.
2. The top of the chain must be a trusted certificate.
3. The current certificate must be signed with the secret key of the previous certificate in the chain

Figure 3: An example of a Certification Path

The reason this is called the Chain of Trust is because the top of the chain gives implicit trust to the rest of the chain. The top certificate in a Chain of Trust is always a well-known and trusted Root CA that is explicitly trusted in the web browser’s certificate store. Since this Root CA is explicitly trusted, any certificates it issues can also be trusted implicitly. This is due to the fact that explicitly trusting a CA means that you also trust that it is only distributing certificates to other trusted sources. That implicit trust trickles down through the Chain of Trust and applies to all Intermediate and Issuing CAs within that chain, as well as the final certificate of the website being verified. Thus, a trusted and secure connection is made between the website and the web browser.

Root Certificates

The Root Certificate is the core of the Chain of Trust, where all trust stems form. The Root Certificate is the certificate of a Root CA. These Root Certificates, or Trusted Certificates, are stored in certificate stores, also known as a Trusted Root Store. These stores contain the certificate and public key of all trusted roots and are pre-built in to the device’s Operating System or through third-party root stores within applications like web browsers. By building these Root Stores into the device before it is in use, the acceptance of many certificates is very quick, as most organizations that use public PKIs use the same ones that are already trusted. This means that any certificates signed by trusted Root CAs are automatically trusted.
Root Certificate Authorities are used to issue certificates to Intermediate and Issuing CAs. When establishing these other CAs, a cross-signed certificate is used as opposed to a regular certificate. A cross-signed certificate is a certificate that is signed by another CA, that is already trusted, for the newly created and untrusted CA. This allows a Certificate Chain of Trust to be created that leads back to an already trusted CA, until such time as the newly created CA has proved its trust and earned its own trusted certificate. Another important point about Root Certificates is that they are issued for a longer period of time than normal certificates. An average certificate is issued for a period of about 4 – 6 months. Root Certificates, on the other hand, tend to be issued for 20 years, as they need to stay valid longer so that the PKI doesn’t collapse.
Root CAs should also never issue certificates to end-users, as the compromise of a Root Certificate would shatter the entire PKI. If a threat actor were to take control of a Root Certificate, they could issue as many certificates as they wanted to any device. This would allow them to infiltrate a network completely undetected and steal sensitive information, plant malicious code into applications, or destroy important infrastructure.  Instead, Intermediate Certificates are used to issue certificates to end-users. Now, let us take a look at Intermediate Certificates.

Intermediate Certificates

Intermediate Certificates are given to Intermediate CAs, which do tasks that Root CAs would commonly do in the past. Since it is insecure to have more than one Root CA, multiple Intermediate CAs are created. Root CAs are kept offline at all times, so Intermediate CAs are act as online Root CAs, without the potential of crippling the entire PKI.
The way an Intermediate CA is created is simple:

1. First, the Root CA signs the Intermediate CA’s certificate, the Intermediate Certificate, with its own private key, thus making that Intermediate Certificate trusted.
2. The Intermediate CA now has the ability to use its Intermediate Certificate to sign end-user certificates.
   • Intermediate CAs can also sign other Intermediate CA’s Intermediate Certificates, creating more links in the Chain of Trust leading back to the Root Certificate.

Using Intermediate Certificate Authorities helps break apart the risk in using CAs. If you think of a PKI as a tree, if an Intermediate “Branch” were to be compromised, that “branch” could be pruned from the PKI, allowing the rest of the PKI to continue to exist. The “root” of the PKI, the actual Root CA, if infected would require the entirety of the CA to be replaced. Intermediate Certificates are vital to the creation of a solid and secure PKI. Intermediate CAs are stored the same as other certificates in the PKI, in a certificate store. A certificate store adds newly trusted CA certificates and end-user certificates to itself for easier certificate validation in the future.

Conclusion

As you can see, though they serve similar functions, Root Certificates and Intermediate Certificates are very different. Root CAs are kept offline and only issue certificates to Intermediate CAs, never to end-users, as their compromise would destroy the PKI. Intermediate CAs act as the online version of Root CAs, but with an Intermediate Certificate rather than a Root Certificate. Intermediate CAs can issue certificates to other Intermediate CAs, or to end-users, for whatever usage they need it for. Intermediate CAs are also slightly different from Root CAs in that their initial certificate is a cross-signed certificate, as opposed to a self-signed certificate, which is what the Root Certificate is. After proving its trust, the Intermediate CA is issued its own certificate, and does not need to rely on the cross-signed certificate any longer.

Without Root Certificates and Intermediate Certificates, the entire Chain of Trust of a PKI is broken. Intermediate CAs are needed for end-user interaction, while Root CAs form the base of the Chain of Trust. When contemplating the design of your own PKI, make sure you utilize both Root Certificates and Intermediate Certificates for the most secure systems possible. For any assistance needed with design and/or implementation of a secure Public Key Infrastructure, you can hire Encryption Consulting’s services. Our experienced team of experts can help you create your ideal PKI.