admin_hub

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
  1. Client Hello / TLS handshake starts. The browser connects and the server presents its certificate chain during the TLS handshake.
  2. 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.
  3. Check the leaf certificate name. The browser checks the certificate's subject alternative names against the hostname it connected to. A mismatch fails immediately.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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)