Name Matching and Revocation: What the Certificate Does Not Tell You

A certificate that chains to a trust anchor proves that some issuer signed some public key. It says nothing about whether that key belongs to the host the client intended to reach, and nothing about whether the issuer has changed its mind since. Both questions are answered outside the chain validation procedure, and both are where most real interop failures live.

The name being checked is not the name in the certificate

The client knows the hostname it dialled, or the hostname it believes it is reaching. The certificate contains a subject field with a common name, and one or more subjectAltName entries. RFC 6125, and the TLS specifications that build on it, are unambiguous: the subjectAltName extension is authoritative and the common name is not consulted when the extension is present. A certificate with a common name of example.com and a subject alternative name of other.example authenticates other.example and nothing else.

This rule was adopted because the common name field is a free-form string with no type constraint that makes it comparable across implementations. Early validators disagreed about whether it should be compared case-sensitively, whether a trailing dot mattered, and whether a wildcard in it was meaningful. Moving identity into a typed extension with a defined matching rule removed the ambiguity.

The extension carries several name forms, distinguished by a type tag. dNSName is the one used for TLS servers and is encoded as an IA5 string. iPAddress is encoded as the raw address bytes, four for IPv4 and sixteen for IPv6, not as a textual representation; a client that compares the textual form will reject a correct certificate, because 192.0.2.1 and the four bytes it denotes are not the same string. uniformResourceIdentifier exists but is not used for TLS server identity. Other forms exist for directories and email.

Multiple dNSName entries are permitted, and any one of them matching is sufficient. This is how a certificate covers several hostnames, and it is why a certificate for a large hosting provider can contain dozens of names.

Wildcards cover one label and only one

A dNSName whose leftmost label is exactly * matches any single label in that position. *.example.com matches www.example.com and a.example.com. It does not match example.com, because the wildcard replaces a label and there is no label to replace. It does not match a.b.example.com, because the wildcard covers one label and a.b is two.

The restriction to the leftmost label is deliberate. A wildcard such as www.*.example.com or *.*.example.com would allow a certificate to cover names in positions that the issuer may not control, and the rule that a wildcard may appear only as the entire leftmost label removes the question. A certificate with f*.example.com is not a wildcard at all; it is a literal name containing an asterisk, which no real host uses and which a validator treats as a non-match for anything else.

Matching is case-insensitive for the ASCII letters, since DNS names are case-insensitive. A trailing dot in the client’s reference identifier is a presentation detail of the resolver, not part of the name, and validators typically normalize it away before comparing. An internationalized name reaches the certificate in its A-label form, the xn-- encoding, so the comparison happens on ASCII even though the user typed something else.

The subjectAltName extension also appears in the ClientHello as server_name, which the server uses to select a certificate. That value is a hint, not a binding: the client must still check the certificate it receives against the name it intended, because the server is free to ignore the hint and because an attacker can rewrite the hint in flight. A server that serves a certificate for the wrong name has produced a validation failure, and the server_name value gives no protection against that. The check itself happens at a fixed point in the handshake sequence, after the certificate message arrives and before the client sends any application data.

Two revocation mechanisms, two different questions

Revocation asks whether an issuer has withdrawn a certificate before its expiry. The certificate itself cannot answer this, because it is a static signed object. The mechanisms that answer it are a list published periodically and a query protocol that returns a signed response per certificate.

A certificate revocation list is a signed, timestamped list of serial numbers issued by one CA. The client downloads it, checks the CA’s signature on it, checks that its thisUpdate and nextUpdate bracket the current time, and looks for the certificate’s serial number. The list is authoritative but coarse: it is refreshed on a schedule the CA chooses, so a certificate revoked between refreshes stays valid to every client until the next list. For a large CA the list is also large, and every client downloads the whole thing to learn one bit. Delta lists and partitioned lists reduce the size, at the cost of more state on the client.

OCSP is a request-response protocol: the client sends the certificate’s serial number and issuer identifiers to a responder, and gets back a signed response asserting good, revoked, or unknown. The response is signed either by the CA or by a delegated responder holding a certificate that the CA issued with the appropriate extended key usage. The response is small, which solves the size problem, and it is fresh, which solves the staleness problem.

It creates two new problems. The first is privacy: the responder learns which certificate the client is checking, which reveals which site the client is visiting, so the query is a tracking channel unless it is proxied or the responses are distributed some other way. The second is availability: if the responder is unreachable, the client must choose between blocking the connection and proceeding without a revocation check. Failing closed breaks the site whenever the responder is down; failing open makes the check optional in practice, which is what an attacker who can block the responder wants.

Stapling moves the fetch to the server

The status_request extension in the ClientHello asks the server to include an OCSP response in its Certificate message. The server, which already has the certificate and can fetch or cache the response, sends it along. The client verifies the response’s signature and freshness and checks that it refers to the certificate in the chain. The client never contacts the responder, so the privacy problem disappears and the availability problem moves to the server, which has better connectivity and a cache.

Stapling solves a different question than fetching does. A fetched response is one the client obtained itself and can trust as current. A stapled response is one the server chose to present, and the client’s only guarantee is that the response is signed by the CA and within its validity window. A server holding a valid but stale response, or one that simply does not staple, produces a connection where the client learns nothing. Some clients treat a missing staple as a soft failure and complete the connection; others treat it as a hard failure. The difference is policy, and it is why a site that staples correctly can still fail on a client that demands stapling while passing on one that does not.

A third mechanism makes the staple mandatory rather than optional, and it lives in the certificate rather than in the handshake. The TLS feature extension, defined in RFC 7633, lets an issuer assert that a certificate requires some feature of the connection, and the relevant feature identifier names OCSP stapling. A client that understands the extension and receives a certificate asserting it must reject the connection when the staple is absent, rather than falling back to no revocation information. The assertion is a property the issuer imposes on every client that honours it, which is useful when the site controls its own stapling and wants the guarantee enforced by certificate rather than by policy. A client that does not implement the extension ignores it, so the enforcement is only as broad as the client population that supports it.

What none of this establishes

The chain validation described in path building and the name check here together establish that a key the client trusts vouched for a name the client wanted. They do not establish that the key has not been misused, that the issuer followed its own procedures, or that the domain’s owner still controls the name. Certificate transparency logs address the first two by making issuance public and auditable, but a client that does not consult a log learns nothing from them.

Revocation is the weakest link in the sequence because it depends on a second fetch that can be blocked, a staple that can be omitted, or a list that can be stale. A certificate that is revoked and still within its validity window is indistinguishable, to a client that performs no revocation check, from one that is not. That is the honest description of the guarantee: revocation checking is a best-effort supplement to expiry, not a replacement for it.

The record layer that follows the handshake has no visibility into any of this. It protects bytes under keys derived from the handshake, and it will protect them just as well for a connection whose name check failed as for one that passed, if the application proceeds. The decision to proceed belongs to the client, and it happens once, before any application data is sent.