SubjectAltName vs Common Name: Why a Certificate Does Not Match the Hostname

When a browser says a certificate is not valid for the requested hostname, many operators still look first at the Common Name.

That is usually the wrong first instinct.

Modern hostname matching is primarily about Subject Alternative Name, or SAN.

The short rule

Current RFC 6125 guidance says:

• if a subjectAltName of type dNSName is present, that must be used as the identity
• Common Name can be used only as a fallback when the relevant SAN is not present
• use of Common Name for this purpose is deprecated

That means the SAN list is the real hostname-coverage surface in modern TLS.

Why this matters in real troubleshooting

A certificate can appear to have a familiar Common Name and still fail hostname verification if:

• the SAN list does not include the requested host
• the SAN list includes different names than the operator expected
• the wildcard in SAN does not match the specific hostname

This is why people can look at a certificate viewer, see a recognizable CN, and still get a hostname mismatch error.

What SAN actually does

Subject Alternative Name is the structured part of the certificate that lists the host identities it is valid for.

For HTTPS hostnames, the relevant SAN entries are usually DNS names.

If the requested host matches one of those SAN identities under the applicable matching rules, the certificate can be accepted. If not, it fails, even if the Common Name looks similar.

Why Common Name is not the real answer anymore

RFC 6125 is explicit that Common Name use is deprecated for hostname identity when SAN is available.

That is important because older habits persist in operations and UI screens:

• people still say "check the CN"
• some certificate viewers still display CN prominently
• some legacy workflows still mentally treat CN as the primary identity

But the hostname-matching logic that matters to modern clients prefers SAN.

The high-value mismatch patterns

1. The SAN list does not include the apex name

A certificate may contain:

• www.example.com
• *.example.com

and still fail on:

• example.com

This is not a "TLS bug." It is a hostname-coverage mismatch.

2. The SAN wildcard is too narrow

RFC 6125 says the wildcard matches only the left-most label.

So:

• *.example.com matches api.example.com
• *.example.com does not match example.com
• *.example.com does not match a.b.example.com

3. The wrong certificate is being served entirely

Sometimes the SAN mismatch is not about a missing name in the intended certificate.

It is because the public hostname is hitting the wrong virtual host or default certificate at the edge.

That is why SNI and host selection still belong in this same troubleshooting path.

Why this belongs in the domain-lookup workflow

Domain lookup gives context for which public hostnames exist and where they terminate:

• apex vs www
• app subdomains
• proxy or edge layers
• shared HTTPS infrastructure

That context matters because hostname mismatch is often a combination of:

• wrong name coverage
• wrong certificate selection
• misunderstanding of which host the user actually hits

The clean troubleshooting order

1. Identify the exact hostname that fails

Do not summarize the error as "the certificate is invalid." Say which hostname is failing.

2. Check the SAN list first

Treat SAN as the primary identity surface, not CN.

3. Apply wildcard rules correctly

Make sure the wildcard actually matches the host you care about.

4. Only then look at CN

If SAN is present, CN is not the leading answer.

5. If the names look correct, verify the public hostname is receiving the intended certificate

At that point, the issue may be SNI, default-server behavior, or another edge-layer selection problem.

Why redirects do not rescue hostname mismatch

Operators sometimes assume:

• the apex cert is wrong
• but it redirects to www
• so it should be fine

It is not fine.

The hostname must be valid at TLS time before the redirect can be trusted.

Common misunderstandings

"The Common Name matches, so the certificate should be accepted"

Not if SAN is present and does not match.

"A wildcard in SAN covers every hostname under the domain"

No.

Wildcard matching is narrower than many people assume.

"This is only a browser warning issue"

No.

Any correct TLS client can reject the hostname if the identity check fails.

FAQ

What do browsers and modern TLS clients check first?

They check the relevant SAN identities first when present, not the Common Name.

Is Common Name deprecated for hostname matching?

Yes. Current RFC 6125 guidance treats Common Name use for this purpose as deprecated when SAN is available.

Why does the certificate still fail even though the CN looks right?

Because the SAN list may not include the requested hostname, or the wildcard rules may not match the hostname the way you assumed.

What should I inspect first when I get a hostname mismatch error?

Inspect the exact failing hostname, then the SAN list, then wildcard applicability, and only after that consider CN or wrong-certificate selection issues.