<b>Why does the certificate chain your server sends differ from the chain the browser actually validates?</b>

<b>Why does the certificate chain your server sends differ from the chain the browser actually validates?</b>

A common misconception is that a TLS server transmits "the" certificate chain and the client checks it as-is. In reality the server sends a Certificate message containing an ordered list of certificates (RFC 8446 §4.4.2), but the client builds its own trust path — and the two can diverge in security-relevant ways.

The server-sent chain is a hint. The client takes the leaf (end-entity) certificate and attempts path construction: it tries to build a chain from the leaf up to a certificate in its own trust store, using the server-supplied intermediates plus any it already caches or can fetch via the Authority Information Access (AIA) extension. The client's local roots are authoritative; the server's claimed root is ignored (and sending the root is wasted bytes).

This divergence is why a single certificate can validate via multiple paths. The canonical case: a cross-signed intermediate. When an older root nears expiry, a CA cross-signs its newer intermediate with both the old and new roots. Clients with the new root in their store validate one path; legacy clients chase the cross-sign to the old root. The Let's Encrypt 2021 expiry of the IdenTrust DST Root CA X3 cross-sign broke exactly the clients that could only reach the old path.

Evidence vs. speculation: path-building is well-specified (RFC 4158); the 2021 DST Root X3 incident is documented fact, not hypothetical.

<b>Further reading:</b> RFC 8446 §4.4.2; RFC 4158 (path building); RFC 5280 §6.

<b>Bottom line:</b> The server proposes a chain; the client disposes by building its own path to a locally-trusted root — serve intermediates generously, never the root, and test against trust stores you do not control, because cross-signs make "valid" client-dependent.