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.
PKI: Are You Doing It Wrong?
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 on, 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.
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 into 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, it 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 basis 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?
An Intermediate Certificate serves as a critical link in the Public Key Infrastructure (PKI) hierarchy, providing a necessary bridge between the root Certificate Authority (CA) and the end-user's certificate. With the expansion of PKI responsibilities, and the replication of root CAs, management complexities arise, and the risk of fraudulent activity increases. To counter this, the concept of Intermediate Certificate Authority was devised. Root CAs delegate specific tasks to these Intermediate CAs, allowing for more streamlined management and enhanced security. Functioning as a surrogate of a root certificate—whose keys are safeguarded by rigorous security layers—an Intermediate Certificate establishes a "Chain of Trust" from the root certificate to the end-entity certificate.
This chain works as follows: The root CA signs the intermediate certificate with its private key, establishing its trustworthiness. Then, this intermediate certificate's private key is used to sign and issue end-user SSL certificates. This process can be repeated, creating a succession of trusted links from the root, through intermediates, and ultimately to the end-entity certificate. This series of trust-establishing links, known as the certificate chain, ensures secure and trustworthy data exchange on the internet.
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 the 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 the Windows environment, you may locate the intermediate certificates in the Intermediate Certification Authorities tab in the 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.
(This post has been updated. It was originally published on September 6, 2022.)