How to Check Certificate SANs and Spot Hostname Mismatches

If you want to check certificate SANs, the main question is simple: does the certificate presented by a service actually cover the hostname you are visiting? The SAN list is where modern TLS clients look for that answer.

That makes SAN inspection useful for troubleshooting browser warnings, validating a CDN or load balancer deployment, and understanding what other hostnames may be tied to the same public certificate.

It is also a practical discovery technique. A certificate can reveal related names such as www, api, login, or regional hostnames even before you inspect the wider DNS footprint.

• A browser or API client reports a certificate hostname mismatch
• A new hostname was added behind a shared TLS endpoint
• You want to confirm whether a wildcard certificate really covers the names in use
• You are auditing what identities a vendor-managed endpoint is serving
• You want extra hostname discovery clues during subdomain review

In each case, the SAN list is not the whole answer, but it is usually the fastest way to confirm whether the certificate and hostname line up.

Look for the exact hostname first. If the request is for app.example.com, the SAN list should include app.example.com or a wildcard such as *.example.com that legitimately covers it.

Be careful with assumptions around wildcards. A wildcard like *.example.com covers one label under the domain, but it does not cover the bare domain example.com and it does not automatically cover deeper names such as a.b.example.com.

Covers:    *.example.com -> api.example.com
Does not:  *.example.com -> example.com
Does not:  *.example.com -> a.b.example.com

A mismatch usually means one of a few operational problems: traffic is landing on the wrong endpoint, the certificate was issued without the intended hostname, or a platform migration left some hostnames behind on an old certificate.

That is why SAN analysis works best alongside DNS and endpoint validation. If the hostname resolves to the wrong service, the certificate problem may only be a symptom of a routing or platform issue.

• Confirm what IPs or CNAME targets the hostname resolves to now
• Check whether the visible certificate belongs to the expected provider
• Compare the SAN list with the hostname users are actually requesting
• Re-test after any DNS or load balancer change to verify the correct endpoint is serving

A SAN entry is useful evidence, but it is not proof that a hostname is active, public, or intentionally exposed today. Certificates can include old names, staging names, or vendor-generated names that are no longer operational.

Treat SANs as strong clues about certificate scope, then confirm with DNS, HTTP, and ownership context before drawing bigger security conclusions.

• Inspect the certificate presented by the live hostname
• Check whether the exact hostname or a valid wildcard appears in SANs
• Compare the certificate issuer and SAN list with the expected platform
• Validate the hostname's current DNS path if the certificate looks unexpected
• Use any extra SAN hostnames as leads for follow-up DNS or certificate review

This keeps SAN checking focused on a real question instead of turning a certificate into an unfiltered list of assumptions.

• Certificate SAN Explorer
• What Is a Subject Alternative Name in TLS?
• How Certificate Transparency Helps Find Subdomains
• Subdomain Finder