What Does Certificate Chain of Trust Mean?
A certificate chain of trust (also known as a certification path) is a sequence of digital certificates needed to validate a certificate issued to an entity by a certificate authority (CA). It allows relying parties to verify that a certificate is valid by checking that it chains up to a trusted root certificate.
Key Takeaways
- A certificate chain links a certificate to the CA’s root certificate through intermediate certificates, proving the certificate’s validity.
- Validation involves checking the signatures on each certificate in the chain using public keys. Each cert is signed by the entity identified by the next cert in the chain.
- A root CA certificate is self-signed and represents the top of the trust hierarchy. All certificates issued by the CA will be chained up to their root.
- Certification paths allow entities to prove they have been issued a valid certificate by a trusted CA without having to share the actual root certificate.
- Browsers, operating systems, and other software maintain lists of trusted root certificates to verify chains of trust automatically.
- Broken chains due to missing intermediate certificates can often be repaired by installing missing intermediates on servers or client machines.
How Does a Certificate Chain Establish Trust?
Public key infrastructure (PKI) uses digital certificates to establish trust online. A certificate binding an entity’s identity to its public key is trusted because it is digitally signed by a certificate authority (CA). But how do we know if we can trust the CA itself? This is where certificate chains come in.
A CA certifies its public key by issuing a self-signed root certificate. This serves as the trust anchor for the CA’s hierarchy of trust. The CA can then issue certificates for intermediate CAs and end-entity certificates that chain up to its self-signed root.
Relying parties can verify certificates by checking the signatures along the chain. Each certificate is signed with the private key corresponding to the public key in the next certificate in the sequence, which proves the child certificate’s authenticity and integrity.
Finally, the root certificate is checked against the relying party’s trust store. This is a collection of trusted self-signed root certificates from many CAs. If a valid path to one of these roots can be established, the end-entity certificate can be trusted.
What are the Components of a Certificate Chain
A certificate chain contains the following certificates:
- End-entity (leaf) certificate: Issued by a CA to an entity such as a user, device, or service. It contains the entity’s public key and identity information.
- Intermediate CA certificates: CAs use these to issue end-entity certificates and other intermediates. Adding intermediates allows the creation of multiple trust branches.
- Root CA certificate: A self-signed certificate representing the top of the CA’s PKI hierarchy. All certificates issued by the CA chain up to this root.
To validate a certificate, the verifier checks the:
- Issuer: The entity that issued and signed the certificate. For intermediates and end-entities, this will be a CA.
- Subject: The identity bound to the public key. For CAs, this is the CA itself. For end-entities, it is the user, device or service.
- Signature: Created when the issuer signs the certificate with its private key. Verifiers use the issuer’s public key to check the signature.
- Chain of trust: Each certificate is signed by the entity identified by the next certificate, linking back to a trusted root.
Why are Intermediate Certificates Used?
Intermediate certificates provide key advantages for certificate authorities:
- Multiple trust branches: Intermediates can issue end-entity certificates and other intermediates. This allows CAs to establish separate trust branches for different types of certificates.
- Reduced exposure of root keys: The root CA certificate is the most sensitive. Intermediates minimize root key exposure by handling routine certificate issuance.
- Ability to revoke branches: If an intermediate key is compromised, its branch can be revoked without affecting other branches or root keys.
- Organizational control: Intermediates may be restricted to certain domains or managed by distinct organizations.
- Improved validation performance: Chains utilizing intermediates improve validation times since root stores are kept lightweight.
How Does Path Validation Work?
There are two primary steps to validating a certificate chain:
How to Prevent SSL Stripping Attacks
SSL stripping exploits weaknesses in older encryption standards and handshakes. Adopting modern protocols and hardening web server configurations can effectively minimize risks:
- Build the certificate path: Retrieve all certificates needed to link the end-entity certificate to a trusted root. This may require locating and downloading missing intermediate certificates.
- Verify the trust path: Check the signature on each certificate using its issuer’s public key to ensure integrity. This proves that each child certificate was issued and signed by the entity identified in the next certificate up the chain.
Once the chain terminates at a trusted root certificate, the end-entity certificate can be considered valid. In the final step, the root’s public key is used to verify its signature.
Some additional checks may include:
- Confirming certificate validity periods have not expired
- Checking revocation status using CRLs or OCSP
- Ensuring compliance with key usage restrictions
- Verifying certificate policies and other extensions
Software such as browsers, operating systems, and TLS libraries that maintain root stores handles automated path building and validation. However, issues occasionally arise requiring manual troubleshooting.
Why do Certificate Chains Break?
The most common cause of broken certificate chains is missing intermediate certificates:
- The server only sends the end-entity cert, assuming the client has the intermediates locally
- Intermediates have been updated, and new versions are not distributed widely
- The certificate deployment architecture was misconfigured
In this case, clients need help locating the necessary intermediates to complete the chain up to a root cert, and installing the missing intermediate usually fixes the issue.
Other potential failure points include:
- An intermediate or root certificate has expired or been revoked
- The end-entity certificate has been revoked, or its name constraints violated
- Signature verification failures or other key errors
Debugging tools like OpenSSL can inspect and validate certificate paths to identify errors preventing trust establishment.
How are Trusted Root Certificates Handled?
Root certificate authorities must be trusted for validation via certificate chains to work. Applications and operating systems maintain collections of trusted self-signed root certificates:
- Root stores: Contains trusted root certificates to serve as trust anchors. Typically, 100-200 roots are from major public CAs.
- Validation: Uses public keys from roots to verify the final certificates in chains. Successful path validation depends on the integrity of these root stores.
- Root stores are updated over time:
- Adding new roots as CAs emerge
- Removing roots if CAs cease operation or are distrusted
Managing the root stores requires great care to ensure the availability of vital CAs without opening the door to compromise. Programs should also allow administrators to modify trust as needed.
What is Cross-Certification Between CAs?
Cross-certification allows CAs to establish trust relationships. It involves two CAs issuing certificates for each other’s public keys. This process can create certification paths in two ways:
- Shared trust anchor: If two CAs chain up to the same root, they automatically trust each other’s certificates.
- Cross-certificates: CAs issue cross-certificates directly to each other to enable trust without a common root. This allows the bridging of disparate PKIs.
In both models, cross-certification enables relying parties in one CA’s hierarchy to validate certificates from the other seamlessly. This is common when consolidating infrastructures after mergers and acquisitions.
How Does Certificate Pinning Work?
Certificate pinning is an alternative trust model that hardcodes information about expected certificates into an application:
- The app stores certificate details like public keys or hashes of trusted endpoints.
- During TLS handshakes, these pinned credentials are used instead of traditional path validation.
- If a server’s certificate does not match expectations, the connection is aborted.
This bypasses the PKI chain and roots to validate servers directly based on whitelisted credentials. It increases security but requires meticulous management to keep credentials updated as certificates expire or are replaced.
Final Words
Certificate chains are a critical component of the public key infrastructure that underpins internet security technologies like HTTPS, S/MIME, VPNs, and more. By linking end-entity certificates back to trusted root certificates via issuer signatures, chains allow entities to prove the validity of their credentials.
Software leverages these chains of trust to authenticate servers, devices, codes, and identities online. While usually invisible to users, issues with broken chains can cause serious usability and security problems. Therefore, understanding certificate chain creation, validation, and management remains an important area of PKI operations.
Frequently Asked Questions (FAQs)
How do you validate a certificate chain in OpenSSL?
You can validate a certificate chain in OpenSSL using the verify subcommand and pass it on to the certificate file. This will check the signatures and validate the chain of trust.
What is a root CA?
A root Certificate Authority is a certificate that is self-signed and represents the top-most entity in a certificate chain hierarchy. All other certificates issued by the CA will be chained up to their root certificate.
What is an Extended Validation Certificate?
Extended Validation (EV) certificates follow strict guidelines for identity verification. They activate the green address bar in browsers to display the validated organization name, providing the highest level of trust.
How does public key infrastructure work?
PKI uses digital certificates and asymmetric encryption to establish entity identities online—a certificate authority issues and signs certificates binding entities to their public keys using their private keys.
What is OCSP, and how does it check certificate status?
The Online Certificate Status Protocol allows checking a certificate’s revocation status in real-time rather than using CRLs. It provides an OCSP responder to query for an up-to-date trust status.
How do I install a root certificate?
You can install root and intermediate certificates on servers or client machines to ensure your local trust store has the certificates needed to validate a full chain. On Windows, use the Certificates MMC snap-in.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
