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.
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:
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:
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.
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.
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.
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.
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.