How does a client validate a certificate chain back to a trusted root?

This is a senior-level question because chain validation is where a lot of real-world TLS failures and misconfigurations live. The interviewer wants to see that you understand trust is transitive and anchored, not magic.

The chain of trust

A server presents a leaf certificate for its hostname. That leaf is signed by an intermediate CA, which is in turn signed by a root CA. The root is self-signed and lives in the client's trust store (shipped with the OS or browser). Validation works upward: each certificate is verified using the public key of the certificate above it, until you reach a root you already trust. If the chain doesn't terminate at a trusted root, validation fails.

Roots sign intermediates rather than leaves directly so the precious root private key can stay offline; if an intermediate is compromised it can be revoked without burning the root.

What gets checked at each link

• Signature — does the issuer's public key verify this certificate's signature?
• Validity dates — is the certificate within its not-before/not-after window?
• Name match — does the leaf's subject/SAN match the hostname the client requested?
• Key usage / constraints — is each CA actually permitted to issue (basic constraints, path length)?
• Revocation — has it been revoked, via a CRL or an OCSP query? OCSP stapling lets the server present a fresh signed status to avoid a client round trip.

Common failure modes

The most frequent real-world break is a missing intermediate: the server sends only the leaf, so clients that don't have the intermediate cached can't build a path to the root. Others include expired certs, hostname mismatches, and untrusted (self-signed or private) roots.

What interviewers look for

The upward walk to a pre-trusted, self-signed root; signature verification at each hop; the validity/hostname/revocation checks; and awareness of why intermediates exist and how a missing one breaks the chain.