A client makes a TLS connection and receives a certificate. List what it must verify before it can claim it is talking to the intended server, and explain why 'the certificate chained to a trusted root' is not sufficient on its own.

## What a certificate is A certificate is a signed statement: an issuer asserts that a particular public key belongs to a particular name, for a particular period, with particular permitted uses. It is entirely public data. It is not a secret, and holding one proves nothing - the copy your browser received is the same copy anyone can fetch. Validation is therefore about establishing several separate things, and a candidate who names only the chain has named one. ## The checks **1. Chain of signatures, with constraints.** The presented leaf certificate is signed by an issuer, which may be signed by another, up to a root that is present in the client's local trust store. Each signature must verify. The constraints in each intermediate matter as much as the signatures: the CA flag marks a certificate as permitted to issue others (its absence historically allowed any leaf holder to mint certificates for other names), path-length limits cap the depth, name constraints can restrict an intermediate to a specific set of domains, and key-usage fields limit what the key may be used for. A validator that checks signatures but ignores constraints is not doing chain validation. **2. Validity window.** Every certificate in the path must be within its notBefore/notAfter dates. This makes correct clocks a security dependency - a device with a badly wrong clock either rejects everything or accepts long-expired certificates. **3. Identity match - the load-bearing one.** The client must check that the name it *intended* to contact appears in the certificate's subject alternative names. Historically the common-name field was used, and modern validation treats it as legacy and does not fall back to it. Wildcards match exactly one left-most label - a wildcard for one level does not cover a deeper subdomain, and partial-label matching is not permitted. Two subtleties. First, the intended name must come from the URL or configuration the application meant to reach, never from anything the server supplies. Second, if you follow a redirect, the new name is the one that must be validated for the new connection. **4. Revocation.** Certificate lists and online status checks exist to declare a certificate invalid before it expires. In practice clients soft-fail: an attacker who can intercept your connection can also block the status query, and a client that treats 'no answer' as 'fine' gains nothing. This is why short-lived certificates - days rather than years - have become the practical answer, with expiry acting as the revocation mechanism, and why automated issuance is a prerequisite. **5. Proof of possession.** The peer must sign something specific to this handshake with the private key matching the certificate's public key. Without this, anyone could copy a certificate from a public site and present it. This is a protocol property rather than a validation library call, but it belongs in the mental model, because it is what makes the certificate mean anything at all. ## Why chaining alone is not enough If a client checks only that the chain terminates in a trusted root, then a certificate for `attacker-owned.example` - legitimately issued, chaining perfectly, unrevoked and in date - passes. The attacker presents it while you believe you are talking to your bank. Every cryptographic check succeeded; you are just talking to someone else. The name check is the sole step that connects 'this is a valid certificate' to 'this is the party I asked for'. ## Where implementations genuinely diverge This is not hypothetical, and the divergence is exactly along the chain/name split. - A **browser** does the whole set by default: chain with constraints, dates, hostname, revocation signals and additional issuance-transparency checks, and it refuses to proceed with a hard error the user must actively override. - A **low-level TLS library** typically verifies the chain when you enable verification but treats hostname verification as a *separate* setting or call. Enable one and omit the other and you have a connection that is cryptographically valid and points anywhere. - **Application-level HTTP clients and language runtimes** have historically varied the most: some shipped with verification effectively disabled or non-fatal by default, some validated the chain but not the name, and behaviour differed between versions of the same library. The practical lesson is that 'it uses TLS' is not a statement about validation, and that the correct question in review is which checks are enabled and where the intended hostname comes from. ## Disabling validation, and the honest alternatives Every real codebase contains the temptation: a self-signed certificate in staging, an expired certificate on a partner system, an interception proxy in the corporate network, or a test that fails. The usual response is a global flag that accepts anything, and that flag then ships. What that flag does is convert TLS into encryption to an unauthenticated peer, which an on-path attacker terminates and relays. The application still reports success, so there is no signal. The correct responses replace an open-world acceptance with a closed-world one. Trust the *specific* internal CA that issues for that environment; trust or pin the *specific* certificate or public key of that one partner endpoint; provision the interception proxy's root deliberately on the machines that need it. The distinction is the whole point: 'accept anything' is open-world and admits every certificate in existence, including the attacker's; 'accept this enumerated set of issuers or keys' is finite, owned by your configuration, and testable. Narrowing trust is the structural control; a flag that widens it to everything is the absence of a control, not a weaker version of one.