Read time: 8 minutes
Basic Entities in the chain of trust
- Root CA Certificate:
The Root CA certificate is a self-signed X.509 certificate. This certificate acts as a trust anchor, used by all the relying parties as the starting point for path validation. The Root CA private key is used to sign the Intermediate CA certificates. If this certificate and its private key is compromised, then the entire certificate chain breaks down and all the certificates signed by this private key will be affected. Hence the Root CA private key must be securely generated and protected at all times. To protect Root CA certificates, intermediate CAs are placed between Root CA and end entities and Root CA never issues certificates to end entities directly. The operating systems, web browsers and custom applications come pre-installed with more than 100 trusted root CA certificates.
- Intermediate CA Certificates:
The intermediate CA certificate sits between the Root CA certificate and the end entity certificate. There can be one or more intermediate CA certificates in the chain of trust. The intermediate CA certificate signs the end entity certificates. This provides an additional layer of security to the Root CA as it can be securely kept offline most of the times.
- End Entity Certificates:
The end entity certificate is the server certificate that is issued to the website domain. When this server certificate is installed on the web server, the URL is changed to HTTPS. This indicates that the website is secure and uses encrypted connection. To receive a digital certificate, an end entity sends a Certificate Signing Request (CSR) to the Issuing CA (Intermediate CA). The CSR contains details about the end entity. The Issuing CA verifies that the information provided is correct and issues the certificate to the end entity.
Types of Trust Models
In the PKI hierarchical trust model, there is an offline Root CA and multiple online Issuing CAs. The multiple Issuing CAs are for high availability and load balancing. This is the most common chain validation process, and it moves in reverse. In this case the validation starts by checking the end entity certificate information against the intermediate certificate that issued the certificate and then checks the intermediate certificate information against the root certificate that issues this certificate.
The web of trust model is an alternative to the hierarchical trust model. It is a decentralized trust model where users manage the trust at the individual key level. There is no certificate authority or a trusted root. Decentralized control of each key pair is the main difference from the hierarchical trust model. PGP (Pretty Good Privacy) uses this trust model.
Path validation is the process of verifying the integrity of the certificate chain, from the end entity to the Root CA. There are some certificate fields and extensions that are used in path validation. These fields are used to define the identity of the certificate and the links between certificates.
- Issuer Distinguished Name
The name of the issuer that signed the certificate.
- Subject Distinguished Name
The identity of the certificate holder.
- Public Key
The public key of the asymmetric keypair.
- Authority Key Identifier (AKI)
The certificate extension that contains the key identifier that is derived from the public key in the issuer certificate.
- Subject Key Identifier (SKI)
The certificate extension that contains the key identifier that is derived from the public key in the subject certificate.
The subject of higher-level certificate is the issuer of the lower-level certificate in the chain. The client searches at different locations to find the certificate that matches the issuer DN in its own certificate. The Distinguished Name (DN) is used to find the certificates and the AKI and SKI values are used to determine if it is a correct certificate. If a certificate authority generates a new keypair, then the SKI value within the certificate should change. The DN of the certificate authority does not change during the rekey process. So, the AKI and SKI values ensure that correct certificate is selected to build the chain. When a client finds multiple trusted certification chains during the certificate chain building process, the best certification chain is selected by calculating each chain’s score. This score is based on the quantity and the quality of the information that the certificate path provides. If the score is the same for multiple chains, then the shortest chain is selected.
Cross certification is the process of interconnecting two PKIs to build certificate chains. The two CAs involved in cross certification sign each other’s CA certificate to establish the relationship in both directions. After the two certificate authorities have established the trust, entities within the separate PKIs can interact with each other depending on the policies mentioned in the certificates.
- Microsoft Certificate Store
Microsoft operating system has built-in certificate stores for trust anchors. Microsoft uses the windows update service to publish trusted root certificates to the certificate stores. The Microsoft Root CA program validates and manages the eligibility for publication of root certificates.
- MAC OSX and Safari
MAC OSX implements a certificate store. MACOSX certificate store is a combination of a certificate store and a password manager. By default, the system has two key chains known as login and system keychains. The user can create more key chains.
- Firefox and other Mozilla based browsers
Mozilla includes a PKCS#11 module that contains trusted root certificates. The user cannot update this certificate store. A user can load additional trusted root CA certificates into the user database.
OpenSSL stores trusted root CA certificates in unencrypted pem files. File system security is very important to protect these files.
For JAVA, the trusted root CA certificates are stored in encrypted form at
<JAVA path>/lib/security/cacerts.The user can update this certificate store.