Before diving into the details of intermediate certificates and certificate chains, let's explore some fundamentals.
What is a certificate authority (CA)?
A certificate authority is a trusted organization that verifies the identity of an entity (i.e., organization A) and signs and issues digital certificates for that entity. This confirms its identity as organization A, which then helps other entities that are establishing communication with organization A confirm that organization A is who it says it is.
What is a root certificate?
A root certificate is a self-signed certificate of the issuing CA and is stored securely in a browser's trust store. The root certificate is an established token of trust in the PKI infrastructure since it validates the identity of the CA, and is used by the CA to sign all other certificates. if the private key is compromised, all certificates signed by the root CA will have to be replaced since the certificate is signed using the private key of the root CA.This is where intermediate certificates come in.
What is an end-entity certificate?
An end-entity certificate or server certificate is the certificate installed on a specific server, website, or device that identifies that entity and enables encrypted communication to and from that entity. End-entity certificates are what you obtain from a CA to secure your website or application— they are at the bottom of the certificate chain.
What is a certificate chain?
A certificate chain, also known as a certification path or chain of trust, is the sequence of certificates from an end-entity certificate up through one or more intermediate certificates to a trusted root certificate. This chain establishes trust by allowing entities to verify that a certificate was legitimately signed and issued by a trusted certificate authority through a path of traceable signatures.
Role of intermediate certificates in the certificate chain
Intermediate certificates help ensure that root CA private keys and certificates are kept securely offline, while handling day-to-day certificate issuance. Root certificate private keys are stored in highly secure facilities with strict access controls, often in hardware security modules (HSMs), and are only accessed for critical operations like signing new intermediate certificates or emergency break-glass events. By keeping the root offline, organizations greatly reduce the risk of the root private key being compromised.
If an intermediate certificate is compromised, only the certificates issued by that specific intermediate certificate are affected. The CA can revoke the compromised intermediate and issue a new one without touching the root certificate or affecting certificates issued by other intermediates. In contrast, if a root certificate was compromised, every single certificate issued under that root would need to be replaced, which would be a massive operational challenge.
Further, intermediate certificates also give organizations a lot more flexibility in how they manage their certificate operations. For example, a CA might set up different intermediate certificates for different levels of validation certificates, geographic regions, divisions, and more,. Thishelps organizations diversify, dilute dependencies on each intermediate certificates, thereby improving overall security.
How certificate chains work
When a certificate authority issues a certificate for a website or server, the CA uses its intermediate certificate's private key to sign the new certificate. This links the end-entity certificate to the intermediate certificate. The intermediate certificate itself was previously signed by a root CA —or potentially another intermediate certificate— creating a trusted, linked chain.
Each certificate in the chain contains the public key and identifying information of its subject (the entity the certificate represents), as well as the digital signature of its issuer — the CA that signed it. The signature is created using the issuer's private key and can be verified using the issuer's public key, which is contained in the issuer's certificate, or the next certificate up in the chain.
This creates a chain where each certificate validates the authenticity of the certificate below it, all the way to the end-entity certificate. The chain ends at the root certificate that's self-signed by the issuing CA and already trusted by the client system.
Certificate chain validation process
When a browser or other client connects to a server, the server presents its certificate along with any necessary intermediate certificates. The client then performs a series of validation steps to verify the entire certificate chain.
First, the client examines the end-entity certificate to verify it hasn't expired, matches the entity/domain being accessed, ensures it hasn't been revoked, and is properly formatted. Next, the client looks at the issuer information in the certificate to identify which intermediate certificate signed it. The client needs access to this intermediate certificate to verify the signature.
Then, the client uses the public key from the intermediate certificate to verify the signature on the end-entity certificate. If the signature is valid, it confirms the end-entity certificate was legitimately issued by that intermediate CA and hasn't been tampered with.
The client then repeats this process moving up the chain to the next certificate. It checks the intermediate certificate, verifies it hasn't expired or been revoked, and checks who issued it. The client then looks for that issuer's certificate, which might be another intermediate certificate provided by the server, or might be a root certificate of the issuing CA, already installed in the client's trust store.
This process continues until the client reaches a certificate that's self-signed by the issuing CA (root certificate). If the client can validate each signature in the chain and the chain ends at a root certificate, the entire certificate chain is considered valid and the connection proceeds. If validation fails at any point due to expired certificates, invalid signatures, missing intermediate certificates, or inability to establish the chain to a trusted root certificate, the client rejects the connection and displays a security warning.
Types of intermediate certificates
Certificate authorities use different types of intermediate certificates for various purposes. Some of the most common types include:
- 01.
Standard intermediate certificates
The most commonly used intermediate certificates are standard intermediate certificates which are certificates authorized to issue end-entity certificates for general purposes. These certificates handle the bulk of day-to-day certificate issuance and signing for websites, servers, and applications. A CA might operate multiple standard intermediates simultaneously to distribute load, for different customer types, or for different regions.
- 02.
Validation-level intermediates
Some certificate authorities create separate intermediate certificates for different validation levels. They might have one intermediate CA dedicated to issuing domain validated certificates, another for organization validated certificates, and a third for extended validation certificates. This separation makes it easier to apply different policies and controls appropriate to each validation level.
- 03.
Cross-signed intermediates
Cross-signing occurs when an intermediate certificate is signed by multiple root certificates, creating multiple valid paths from that intermediate to different trusted root certificates and established CAs. CAs use cross-signing when deploying new root certificates that aren't yet widely trusted, either in the case of root certificate transitions or when it is a new CA that is yet to be established, or to be compatible with older systems that trust legacy root certificates only. If a client doesn't trust one root, it might trust another root that also signed the same intermediate, allowing the validation to succeed via an alternate path.
- 04.
Subordinate CA certificates
In large organizations or enterprise deployments, subordinate CA certificates function as intermediate certificates issued to specific divisions, departments, or purposes within an organization. A company might obtain a subordinate CA certificate from a public CA, then use that subordinate CA to issue certificates for internal use, maintaining control over their own certificate issuance while still chaining to publicly trusted root certificates.