For nearly two decades, the rule "check that the certificate matches the hostname" was folklore. Every protocol — HTTPS, SMTP over TLS, IMAP, XMPP, LDAP — reinvented the wheel, and each one did it slightly differently. RFC 6125 finally wrote down, in one place, what "matches" actually means. It is the reason your TLS library rejects *.example.com for foo.bar.example.com, and why CN= is quietly being retired.

The problem it solves. RFC 2818 (HTTPS) gave rough guidance for browsers in 2000. RFC 2830 said something else for LDAP. RFC 3207 for SMTP was vague. XMPP had its own rules involving id-on-xmppAddr. Implementers had to synthesize half a dozen specs — and got it wrong. Notorious bugs like the null-byte CN attack (Moxie Marlinspike, 2009), where a cert for www.paypal.com\0.evil.com matched www.paypal.com in naive C string comparisons, showed the cost of ambiguity. RFC 6125 tries to unify the rules and close these holes.

Key design decisions.

• Deprecate Common Name. The CN field of the certificate Subject was never meant to hold DNS names — it was a human-readable label. RFC 6125 says clients MAY fall back to CN but only if no subjectAltName (SAN) of type dNSName is present. Modern clients (Chrome since 58, most libraries) now reject CN outright.
• SAN is authoritative. Certificates must list every service identity in subjectAltName. The reference identifier the client uses to compare comes from the user or configuration ("the URL bar said mail.example.com"), not from the cert.
• Wildcard rules, finally pinned down. A wildcard label may appear only as the leftmost label (*.example.com ✓, foo.*.example.com ✗). It matches exactly one label — *.example.com matches a.example.com but not a.b.example.com and not the bare example.com. Partial wildcards like f*.example.com are discouraged, and most clients reject them.
• Three identifier types. DNS-ID (a hostname), SRV-ID (service+hostname, e.g., _xmpp-server.example.com), and URI-ID (a full URI). SRV-ID was a big deal for XMPP and CalDAV, which use SRV records to indirect hostnames.
• Reference vs. presented identifiers. The spec introduces careful vocabulary: the reference identifier is what the client expects; the presented identifier is what the cert offers. Matching is a set operation, not a scan-for-first-hit.

Why it matters today. Every TLS-enabled protocol now cites RFC 6125 by reference instead of writing its own matching logic. When Let's Encrypt issues you a cert, the SAN list follows these rules. When Go's crypto/tls, Python's ssl module, or OpenSSL 1.1.0+'s X509_check_host() validate a hostname, they implement 6125. It also underpins later specs like RFC 7525 (TLS BCP) and RFC 9525 (which replaces 6125 in 2023, tightening wildcards further and formally killing CN fallback).

Quirky history. The document was chaired through IETF by Peter Saint-Andre, who had spent years dealing with XMPP's identity mess. It took over two years of debate — largely about wildcards. Should *.example.com match example.com? (No.) Should * alone ever be valid? (No.) What about internationalized domain names? (Compare A-labels, never U-labels.) The wildcard section alone is nearly a third of the RFC — because that's where every deployed implementation had disagreed.