How is a certificate chain validated, and what goes wrong in practice?

TL;DR: The client builds a chain from the server's leaf through intermediates to a root in its trust store, then checks every link: signature, validity dates, that each signer is a CA (basic constraints), key usage, and that the leaf's Subject Alternative Name matches the requested host. Where required, it also checks revocation and Certificate Transparency proofs. In practice things fail through disabled verification, missing hostname checks, expired certificates, overly broad trust stores, and revocation checks that fail open.

How to approach it

List the checks in order so the interviewer hears a complete procedure, then spend most of the time on failures, ideally ones you have seen. Tie failures to impact: which attacker each one enables.

A strong answer

The procedure.

1. Build the chain. Leaf (sent by server) to intermediates (sent by server) to a root (already trusted by the client).
2. Verify signatures at each link with the issuer's public key.
3. Check validity periods for every certificate.
4. Check basic constraints: every certificate that signed another must be marked as a CA, within path-length limits.
5. Check key usage: the leaf is allowed for server authentication.
6. Match the name: the requested host matches a SAN entry (wildcards cover one label only).
7. Check revocation and CT where policy requires: CRLs or OCSP, and signed certificate timestamps for public certificates.

What goes wrong.

The practical defences. Use the platform's validator and never disable it; pin to a specific internal CA (not a leaf) for service-to-service calls; automate issuance and renewal (ACME); monitor Certificate Transparency logs for your domains; prefer short-lived certificates, which the industry is moving toward (the CA/Browser Forum approved a phased reduction to 47-day maximum lifetimes by 2029, checked November 2026).

AI context. Agent frameworks, notebooks and internal tool servers are common places to find verify=False. An agent that calls a tool server without verification can be fed forged tool responses by anyone positioned on the network, which is an injection channel as well as a confidentiality problem.

Name matching, in code. The hostname check is small enough to read in full. This sketch follows the RFC 6125 rules most clients apply: a wildcard only as the whole left-most label, matching exactly one label, never a bare public suffix.

def matches(pattern: str, host: str) -> bool:
    """Hostname check in the style of RFC 6125: a wildcard only as the whole
    left-most label, matching exactly one label, never a public suffix alone."""
    p, h = pattern.lower().rstrip("."), host.lower().rstrip(".")
    if "*" not in p:
        return p == h
    p_labels, h_labels = p.split("."), h.split(".")
    if p_labels[0] != "*" or "*" in ".".join(p_labels[1:]):
        return False  # partial or non-left-most wildcards are rejected
    if len(p_labels) < 3:
        return False  # "*.com" style patterns are never accepted
    return len(h_labels) == len(p_labels) and h_labels[1:] == p_labels[1:]


def check(sans: list[str], host: str) -> str:
    return "ok" if any(matches(s, host) for s in sans) else "name mismatch"


sans = ["api.example.com", "*.cdn.example.com"]
print(check(sans, "api.example.com"))  # => ok
print(check(sans, "img.cdn.example.com"))  # => ok
print(check(sans, "a.b.cdn.example.com"))  # => name mismatch
print(check(sans, "example.com"))  # => name mismatch
print(check(["*.com"], "evil.com"))  # => name mismatch

What interviewers probe next

• "Why is revocation so unreliable?" CRLs are large and stale, OCSP adds latency and privacy leakage, and clients soft-fail; shorter lifetimes limit the damage instead.
• "Should you pin certificates?" Pin to a CA or public key you control for internal clients if you can manage rotation; leaf pinning in public apps causes outages when certificates rotate.
• "How do you find disabled verification in a large codebase?" Static analysis rules for the known flags and APIs, plus tests that connect through an intercepting proxy and expect failure.

What if?

How it's scored

Weak: Says the client "checks the certificate is signed" and stops.

Hire: Lists chain building, signatures, dates and hostname, and names disabled verification as a common failure.

Strong Hire: Covers basic constraints, revocation behaviour, CT monitoring and lifetime trends, and gives concrete detection and prevention practices.

Common mistakes

• Matching the host against the Common Name instead of SANs.
• Pinning leaf certificates in clients that cannot be updated quickly.
• Treating a "temporary" disabled check as harmless.
• Assuming internal networks do not need validated TLS.