Certificate name verification: wildcards, SANs and the checks that fail open

Identity is a separate question from trust

A certificate chain can be valid while the name on it is wrong for the service being contacted. Chain validation answers whether a trusted authority issued the certificate; name verification answers whether the certificate describes the host the client intended to reach. Libraries implement them as separate steps, and the second step is the one most often weakened by application code that calls a low-level API and forgets it.

RFC 6125 described the matching rules for domain-based service identity. RFC 9525 updated them for TLS, and both share the same core requirement: the identity is matched against dNSName entries in the subjectAltName extension.

What the modern rules require

The subjectAltName extension is authoritative. The commonName field is legacy and is no longer a fallback for deciding which host a certificate is valid for. A client that still consults commonName accepts certificates that the modern rules reject.

Wildcards are permitted only in the leftmost label, and only as the entire label. A name such as .example.com matches www.example.com and api.example.com. It does not match example.com itself, because a wildcard must occupy at least one label, and it does not match a.b.example.com, because the wildcard covers a single label. A pattern such as w.example.com or *.api.example.com sits outside the permitted form and should be rejected by a conforming client.

Case does not matter for the comparison. Internationalised names are compared in their ASCII-compatible encoding, which is why two registrations of the same name can look identical on screen while differing in their A-label representation.

Where implementations fail open

Four mistakes recur in application code that performs its own verification.

The first is disabling verification and compensating with an explicit hostname check somewhere else in the call path. The compensating check is usually attached to a code path that a retry or a redirect bypasses. The second is writing a custom matcher that uses string suffix comparison, so that notexample.com matches example.com. The third is accepting a certificate with an empty subjectAltName when the code falls back to commonName. The fourth is pinning to a certificate or public key without planning for rotation, which produces an outage that a maintainer resolves by removing the pin.

Each of these turns a strong protocol property into an application-level decision that is not tested against the failure case.

Verifying a deployment

For a host that serves several names, confirm which names appear in subjectAltName and check that a wildcard is not silently covering a name it should not. A certificate for *.example.com presented for example.com or for a.b.example.com should be rejected, and testing those two cases is a quick way to find a matcher that is doing suffix comparison.

Where certificate pinning is used, record the pinned value, the rotation plan and the party who owns the update. Where a client is expected to verify, confirm the failure path by pointing it at a certificate for the wrong name and observing that the connection is refused rather than accepted with a warning.

For internal services the same rules apply, and private certificate authorities make it tempting to issue broad wildcards for convenience. A wildcard that covers an entire internal namespace converts a single key compromise into the ability to impersonate every service in that namespace.

References

1. RFC 6125, Representation and Verification of Domain-Based Application Service Identity. https://www.rfc-editor.org/rfc/rfc6125.html
2. RFC 9525, Service Identity in TLS. https://www.rfc-editor.org/rfc/rfc9525.html
3. RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile. https://www.rfc-editor.org/rfc/rfc5280.html