A TLS client decides whether a certificate fits a server by comparing the name the user asked for against the DNS names in the certificate's subjectAltName extension. A trusted CA signature alone is not enough. If the names do not match, the connection should fail, and turning that check off is a serious bug.
The matching rule
RFC 6125 describes how a client builds its reference identifier. It comes from the domain the user or program asked to reach, never from whatever the server presents. The client then compares that name with each dNSName entry in the certificate's subjectAltName. Names are compared label by label, ignoring ASCII case. If any presented identifier matches, verification succeeds.
If nothing matches, an interactive client should warn the user and stop, and an automated client should terminate the connection with a bad certificate error, unless the certificate was previously pinned.
Wildcard rules
Wildcards are optional for clients and tightly limited:
- A wildcard may appear only in the left-most label.
*.example.commatchesfoo.example.com.- It does not match
example.comitself, and it does not matchbar.foo.example.com. - Partial label wildcards such as
baz*are allowed by the RFC, but not inside internationalized labels.
The RFC also advises servers to avoid wildcard certificates where possible, because one certificate vouches for every host in the domain. If the private key leaks from one service, an attacker can impersonate all of them.
Why not the Common Name
The Common Name field is not strongly typed. It may hold a human friendly label instead of a hostname, and a certificate can carry several of them. RFC 6125 says clients must not check the CN if the certificate has any DNS-ID, SRV-ID, URI-ID or other supported identifier. Using the CN is permitted only as a last resort when none of those are present, and certificates should not include a CN-ID unless a specification requires it for compatibility.
In practice: put every name you serve in the SAN list, including the bare domain if you also serve it.
Where this goes wrong in code
- Disabling verification to get past a staging error, then shipping the setting.
- Connecting by IP address with a certificate issued for a hostname.
- Passing the wrong name when the client sets the server name separately from the connect address.
- Treating a wildcard as covering the apex or nested subdomains.
For related failure modes, read certificate validation bypass and man in the middle risk and ignoring Docker registry certificates as an anti pattern.
A review checklist
- Search the codebase for settings that disable verification.
- Confirm each service certificate lists all served names in the SAN.
- Check that wildcard use is deliberate and limited to what needs it.
- Make sure test and production use the same verification path.
Where Safeguard fits
Safeguard does not run your DNS, certificates or network routes. It covers the code around them: dependency and SBOM scanning, reachability analysis and policy gates for the libraries your applications use. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does *.example.com cover example.com?
No. Under RFC 6125 matching, the wildcard stands for one label, so the bare domain needs its own entry.
Can I rely on the Common Name?
Only as a last resort when no other identifier is present. Put names in the SAN list instead.
Sources
Last reviewed: 19 October 2026.
