Chains of trust and path validation

A certificate chain answers a recursive question: who vouched for this key, and who vouched for them? Validation stops when it reaches a certificate the client already trusts.

Root keys are enormously valuable and are kept offline, often in hardware, for years. If a root signed every website certificate directly, it would have to be online constantly. Intermediates solve that: they are signed occasionally by the root and then used heavily.

If an intermediate is compromised, the CA can revoke just that intermediate and keep the root. That is exactly what happened in the 2026 eMudhra incident, where several intermediate keys were found to be catastrophically weak.

• Cross-signing lets a new root borrow trust from an old one while devices catch up
• Short-lived intermediates reduce the value of a key that leaks
• Clients differ in which roots and intermediates they ship, which is why one chain can be accepted by a browser and rejected by a Java runtime

1. 1

   Build candidate paths

   Collect certificates from the server and the local store that could connect the leaf to a trusted root.

2. 2

   Check signatures

   Each certificate must be signed by the key of the next one, up to the trust anchor.

3. 3

   Check validity dates

   Every certificate in the path must be currently valid.

4. 4

   Check names

   The requested hostname must appear in the leaf's Subject Alternative Name.

5. 5

   Check constraints

   Basic Constraints, Key Usage and EKU must permit the intended use; path length limits must hold.

6. 6

   Check revocation

   Revocation data, where the client uses it, must not mark any certificate as revoked.

Only if every step succeeds is the chain accepted. This is why a single missing intermediate breaks everything, even though the leaf itself is perfectly valid.