Why does the absence of unrecognized_name(112) prove nothing when a server holds no certificate for the requested host_name?

## What the specification actually permits RFC 6066 defines the `server_name` extension and, with it, what a server does when it understood the extension but does not recognise the `host_name` inside it. The server SHOULD take one of two actions: 1. abort the handshake with a fatal-level `unrecognized_name(112)` alert, or 2. continue the handshake. The same text adds that sending a **warning-level** `unrecognized_name(112)` is NOT RECOMMENDED, because a receiver's behaviour on warning-level alerts is unpredictable. Read those strengths carefully, because the whole diagnostic point sits in them. Continuing is a listed, conforming action. Nothing obliges a server to announce that it does not know the name, and plenty of deployments have no notion of an "unknown" name at all - they have a default and they serve it. ## What "continue" looks like from the outside When the server continues, the handshake proceeds normally up to the point where the validating peer inspects what it was given. The peer applies its own checks, finds the certificate unsuitable for the name it asked for, and aborts with a certificate-shaped verdict such as `bad_certificate(42)`. The result is a failure whose description points at a certificate, produced by a cause that was a name. That is the trap: the alert you receive is an accurate report of the verdict the sender reached, and a misleading report of why the connection was doomed. ## Why silence is not evidence - The specification never required the alert, so its absence is consistent with every possible server behaviour. - A server with a single default certificate may never evaluate the name at all. - A warning-level one is discouraged, and under TLS 1.3 would be treated as an error regardless of the level claimed - so implementers who do not want to abort simply send nothing. - The peer that answered may be running a version or a configuration in which the name never influenced the choice. ## What each observation licenses | Observation | What it supports | Strength | |---|---|---| | Fatal `unrecognized_name(112)` received | The server positively declined the name | Strong | | Warning-level `unrecognized_name(112)` | Discouraged by the specification; intent unclear | Ambiguous | | No alert, then a certificate verdict from the validator | Consistent with an unknown name and with several other causes | Weak | | No alert, handshake completes and is accepted | The name was served, or the default was acceptable for it | Strong | ## The test that does work 1. Hold everything else constant - same peer, same offered parameters - and vary only the `host_name` carried in `server_name`. 2. Observe whether the failure moves. A failure that disappears for one name and not another is a name-driven failure, whatever description the alert carried. 3. Read the validating peer's verdict as the evidence, not the server's silence. This is the shape of almost every good TLS diagnosis: change one input, watch whether the symptom follows it, and stop treating an absent alert as a negative result. ## The wider lesson about optional behaviour Specifications are full of behaviour a peer MAY or SHOULD exhibit, and every one of those is a place where absence carries no information. An answer that says "there was no `unrecognized_name(112)`, so the name is fine" has promoted a SHOULD-choose-one-of-two into a MUST, and it will send an incident down the wrong path - usually towards re-issuing a certificate that was never the problem. The converse also holds and is worth stating: when the fatal alert *does* arrive, it is a positive, unambiguous statement from the server that the name was refused. Optional behaviours are weak as absences and strong as presences.