Certificate chains

A certificate chain is an ordered list of one or more certificates, in which each subsequent certificate is the issuer of the previous certificate.

During TLS negotiation, the server presents a certificate chain to the client so that the client can determine whether it should trust that chain and continue with the negotiation. The client can optionally present its own certificate chain to the server.

If a certificate is self-signed, then its chain contains only that one certificate. If a certificate was signed by a root certificate authority (CA), that is, a self-signed certification authority certificate, then the chain contains two certificates: the server certificate followed by the CA certificate. If there is a single intermediate CA, then the chain contains the server certificate, followed by the intermediate CA, and finally the root CA, and so on.

Intermediate certification authorities are useful security purposes, especially for commercial CAs or other widely trusted authorities. If a client trusts a root CA certificate, then it likely trusts anything that has that root CA certificate at the base of its chain. This means that it’s critical to keep the root CA certificate secure, because if it is compromised, then any certificate signed by it (whether directly or indirectly) can no longer be trusted. With intermediate CA certificates, the root certificate can be kept offline in very secure storage and only used whenever it is necessary to sign a new intermediate CA certificate. The intermediate CA certificates can be the ones to sign end-entity certificates. They should also be extremely well-guarded because it would be disastrous if one of them were compromised requiring it and all certificates it signed had to be revoked, but at least the root CA could be used to sign a new intermediate CA certificate, and that could then be used to sign replacements for all certificates that had been issued by the former CA certificate.

If the root CA at the end of the chain is widely trusted, then the server might assume that the client already has that root CA in its default set of trusted certificates and leave it off the chain with the assumption that the client will retrieve it from its default trust store. While the same could theoretically be true for intermediate CA certificates, only the root CA certificate is commonly omitted. Upon receiving such an incomplete chain, the client should look in its default trust store to see if it contains the issuer certificate which it can identify using things like the issuer DN or an authority key identifier extension.

The certificate at the head of a certificate chain (the first one in the list) is often called the end-entity certificate. If it’s at the head of a chain presented by a server during TLS negotiation, then it can also be called the server certificate, whereas if it’s at the head of a chain presented by a client, then it can also be called a client certificate. The certificate at the tail of the complete chain must be a root CA certificate. In the case of a self-signed certificate, the chain contains only a single certificate that serves both of those roles.