Why Doesn't My SSL Certificate Match My Domain? SAN and SNI Explained

When a browser says the certificate does not match the domain, the easy conclusion is that the certificate was requested incorrectly. That can be true, but often the certificate itself is fine: the visitor used another hostname, the server chose its default certificate because SNI was absent, or DNS sent some traffic to an endpoint that still serves an older certificate.

The investigation becomes much simpler when you answer two questions independently: what hostname did the client ask for, and what certificate did the public TLS endpoint actually return? Once those facts are separate, errors such as NET::ERR_CERT_COMMON_NAME_INVALID stop being mysterious.

Begin with the SSL Checker against the public hostname. It reports the hostname result, the served chain, and resolved addresses. Then use the Certificate Decoder to read the certificate’s Subject Alternative Names.

Name coverage comes from SAN, not the filename or Common Name

Modern clients use the Subject Alternative Name (SAN) extension to decide which names a certificate covers. A Common Name may still be displayed, but it is not the reliable source for hostname coverage. Filenames, order labels, and console notes do not prove anything here either.

Open the leaf certificate returned by the public endpoint and compare every DNS SAN with the complete hostname in the visitor’s address bar. Do not settle for seeing a company domain “somewhere in the list”; the exact requested name must be covered.

A wildcard replaces one label, not an entire hierarchy

*.example.com can cover api.example.com, but not example.com and not v2.api.example.com. The asterisk represents one label between dots; it is not permission for every nested name below a domain.

Before requesting a certificate, make an inventory from real entry points: apex, www, APIs, administration, regional subdomains, and hostnames used by monitoring. Include names that will be moved soon in the renewal or replacement plan, rather than discovering a missing SAN during a cutover.

SNI tells the server which certificate to choose first

One IP can serve many HTTPS names. TLS happens before the HTTP request, so the server cannot use the full URL path to choose a certificate. The client sends SNI to say which hostname it expects, and the server selects a certificate from that value.

If a test connects only to an IP, a monitor omits SNI, or a proxy changes the SNI name, the server will often return its default site’s certificate. That certificate may be perfectly valid—just not for the name the visitor intended to reach.

Test with the real hostname, and when you test an IP, explicitly supply the expected SNI. Compare the same IP with and without that SNI: different certificates mean selection changes by request or node. If the wrong certificate still appears with correct SNI, inspect the matching virtual-host, ingress, or load-balancer rule.

DNS, CDNs, and load balancers can route visitors to an old endpoint

Correct SANs and correct SNI still do not guarantee the client reaches the intended server. After a migration or certificate change, IPv4 may be updated while IPv6 still reaches an old service; a CNAME may lead through a CDN, platform, or several load-balancing layers.

Use DNS Lookup to inspect A, AAAA, CNAME, and TTL records, and follow CNAMEs far enough to identify the actual public edge. A low TTL does not make every recursive cache forget an older answer immediately; it only limits how long that cache may retain an answer after receiving it. For intermittent failures, test each resolution and backend node.

The certificate on disk may not be the one serving the public internet

Many investigations stop at “the certificate on my server has the right SANs.” The public TLS terminator may be a CDN, cloud load balancer, Kubernetes ingress, reverse proxy, or even an old server that never left service. A correct backend configuration only proves the backend is correct.

Treat the serial number or SHA-256 fingerprint from the public handshake as the source of truth. Trace the traffic path to the TLS terminator that returns that certificate. If one edge still serves the old certificate, update and reload that edge, then verify it publicly instead of changing the application server again.

The form of the hostname can change the result

Visitors do not always use the canonical address you had in mind. They may enter a bare IP, an old name, an internal alias, or a hostname with a typo. Internationalized domain names are commonly represented as Punycode in certificates and DNS, so compare the hostname actually used in the handshake rather than only what a UI happens to display.

Certificate matching answers only whether the requested name is covered. If the certificate and chain are correct but one network still sees an unfamiliar certificate, also rule out corporate HTTPS inspection, captive portals, and security software replacing the connection.

A practical order from error to fix

1. Record the complete hostname and browser or client error; do not reduce it to “certificate mismatch.”
2. Check that public hostname with the SSL Checker, including the real port and SNI where necessary.
3. Open the public leaf in the Certificate Decoder and compare its DNS SANs with the requested hostname.
4. Check the apex, www, wildcard depth, nested subdomains, and IP access against the intended coverage.
5. Compare the same IP with and without expected SNI, then inspect hostname routing at the CDN, load balancer, or ingress.
6. Use DNS Lookup for A, AAAA, CNAME, and every possible public entry point; make sure no old node still returns the wrong certificate.
7. Fix the real TLS terminator and repeat the public handshake over IPv4, IPv6, and the client that originally failed.

If name coverage passes but clients still cannot trust the certificate, stop changing SANs. The next layer is the chain: read Why Is My Certificate Chain Incomplete?. For the broader troubleshooting map, see Why Is My SSL Certificate Invalid?.