sysop@hub:~/explainers/pki-chain-explained$
pki-chain-explained
How certificate chain validation works
What a browser actually checks when it shows the padlock, from the leaf certificate up to a trusted root.
Read the steps as text
- Client Hello / TLS handshake starts. The browser connects and the server presents its certificate chain during the TLS handshake.
- Server sends leaf + intermediate certificates. The server should send its own certificate plus any intermediate certificates, but not the root. A common misconfiguration is sending an incomplete chain.
- Check the leaf certificate name. The browser checks the certificate's subject alternative names against the hostname it connected to. A mismatch fails immediately.
- Walk up to the intermediate's issuer. The browser follows the chain: the leaf was signed by the intermediate, so it checks who signed the intermediate.
- Is the issuer in the trusted root store?. The browser checks whether the top of the chain is a root certificate already trusted by the operating system or browser.
- Root found and trusted. If the root is present and trusted, the chain is valid so far. If not, the browser shows a trust error, for example certificate not trusted.
- Check validity dates. Every certificate in the chain must be within its notBefore and notAfter dates. An expired intermediate breaks the whole chain, even if the leaf is still valid.
- Check revocation (OCSP or CRL). The browser may check whether the certificate has been revoked, using OCSP or a certificate revocation list, depending on browser and certificate settings.
- Establish the encrypted connection. Once the chain validates, the browser and server complete the key exchange and the connection is encrypted. The padlock appears.
Common failures
- Incomplete chain: the server does not send the intermediate certificate. Works in some browsers that cache the intermediate, fails in others. Fix by installing the full chain on the server.
- Expired intermediate: the leaf certificate is fine but an intermediate in the chain has expired. Very common after a CA rotates intermediates.
- Name mismatch: the certificate does not cover the hostname used, including a missing www or a wildcard that does not match a sub-subdomain.
- Untrusted root: usually a self-signed or internal CA certificate that has not been installed in the device's trust store.
- Clock skew: if the client's system clock is very wrong, valid certificates can appear expired or not yet valid.
Related: OpenSSL cheat sheetCryptography quick referenceDNS record types (CAA)