When a TLS client checks a certificate, it compares the host name it meant to reach against the dNSName entries in the Subject Alternative Name extension. It does not use the Common Name. If your name is not in the SAN list, the connection fails, and that failure is a security feature, not a bug.
What RFC 9525 says
RFC 9525 specifies how services are identified when TLS uses X.509 certificates, and it replaces the older RFC 6125. Key points:
- DNS names are checked only through the dNSName entry in subjectAltName, called a DNS-ID.
- The Common Name must not be used to identify a service, because it is free-form text.
- Certificates need at least one identifier, and issuers should include a DNS-ID for interoperability.
- Clients build their own reference identifier from the name they were asked to connect to, without looking at what the server presents first.
- Matching is case-insensitive for DNS labels.
- IP addresses match exactly, octet for octet, with no partial or network level matching.
- A wildcard may appear only as the entire left-most label and matches exactly one label.
On a mismatch, an automated client should end the connection with a bad certificate error. A human operated client should warn and end by default.
Why the check exists
Anyone can get a valid certificate for some name. The hostname check is what binds that certificate to the server you intended. RFC 9325 calls host name validation security critical: without it, the connection may not end at the intended endpoint. This is why disabling certificate verification to make a test pass is dangerous.
Common causes of a mismatch
- Name missing from the SAN. You added a new alias or subdomain and forgot to reissue.
- Apex versus www. A certificate for
www.example.comdoes not coverexample.com. - Wildcard depth.
*.example.comcoversapi.example.com, nota.b.example.com. See wildcard or per-host certificates. - Connecting by IP address. The certificate lists DNS names, not that IP.
- Wrong certificate served. A server hosting several names picks the certificate from the requested server name, and falls back to a default certificate when it does not match. RFC 9325 says servers that do not recognize the name should fail with an unrecognized_name alert.
- Old certificate cached by a proxy or CDN.
- Legacy client relying on the CN. Old software may still read the Common Name, but you should not design around it.
How to diagnose
Inspect the certificate the server actually serves for the exact name you request, with the server name sent. List its SAN entries and compare them character by character with your target. Repeat from outside your network, since split DNS can point internal users to a different server than external users.
How to fix it
- Reissue with every needed name listed in the SAN.
- Match what clients really type: apex, www, and any alias.
- Use a name in the certificate instead of an IP address in client config.
- Fix the client rather than loosening verification. Never ship code that skips the check.
Quick check
Can I just put the name in the Common Name?
No. RFC 9525 says the Common Name must not be used to identify a service, so modern clients ignore it for matching.
Does a wildcard match the bare domain?
No. It matches one label to the left. List the bare domain as a separate SAN entry.
Sources
Last reviewed: 19 October 2026.
