Apex versus www
A certificate that covers www.example.com does not automatically cover example.com. Include both when both hostnames are served.
SSL Certificate Hostname Mismatch: Causes and Fixes
A hostname mismatch means the TLS certificate presented by the server does not identify the hostname the client requested. Fix the name or endpoint mismatch—do not bypass certificate validation.
What a hostname mismatch actually means
When a client opens https://shop.example.com, it verifies that the certificate presented by the TLS server identifies shop.example.com. The current IETF service-identity specification, RFC 9525, says DNS service identities are checked using dNSName entries in the Subject Alternative Name (SAN) extension; the Common Name should not be used as the service identity.
If none of the certificate's relevant SAN entries match the requested hostname, verification fails even when the certificate is unexpired and signed by a trusted certificate authority.
Common mismatch patterns
Missing subdomain
A certificate for example.com does not cover api.example.com unless that subdomain is explicitly present or a valid wildcard covers it.
Wildcard expectation is wrong
A wildcard such as *.example.com matches a single left-most label such as api.example.com; it does not identify the apex example.com or deeper names such as a.b.example.com.
Wrong certificate is served
DNS, SNI, a default virtual host, CDN or load balancer can route the request to infrastructure that presents a certificate for a different site.
Step 1: identify the exact hostname that fails
Write down the hostname from the address bar or API endpoint exactly as requested. Test apex and www separately. A redirect does not rescue the first TLS handshake: the browser must establish HTTPS with the original hostname before it can receive an HTTP redirect.
That is why “redirect the uncovered hostname to the covered hostname” is not a complete certificate fix. The first hostname still needs a valid certificate if users connect to it over HTTPS.
Step 2: check what the public endpoint serves
Run the hostname through the SSL Checker. The checker uses hostname verification during the TLS connection. If the connection validates, review the returned SANs, subject, issuer, validity window and endpoint IP. If it fails with a certificate validation problem, use your server/provider certificate view or a command-line TLS client to inspect the invalid certificate in more detail.
DigiCert's certificate guidance describes the same core rule: browsers compare the requested host with names the certificate is valid for, and a mismatch can occur when users connect through a different hostname or IP than the certificate covers.
Step 3: compare SAN coverage with the hostname
| Requested hostname | Certificate SAN | Expected result |
|---|---|---|
| www.example.com | www.example.com | Exact DNS-name match. |
| api.example.com | *.example.com | Wildcard can match one left-most label. |
| example.com | *.example.com | Mismatch: wildcard does not cover the apex. |
| v2.api.example.com | *.example.com | Mismatch: wildcard is not a multi-label catch-all. |
| 203.0.113.10 | example.com | Mismatch unless the certificate contains a matching IP identity. |
Step 4: verify DNS is sending the hostname to the intended infrastructure
Use the DNS Checker to inspect A, AAAA and CNAME. A correct certificate can be installed on one server while DNS sends users to another server with a default certificate. This is especially common during hosting migrations, CDN changes and partial IPv6 rollouts.
If a DNS change was recent, compare resolver answers with the DNS Propagation Checker. Intermittent mismatch errors can happen when some resolvers still send users to an old endpoint.
Step 5: inspect SNI, virtual hosts, load balancers and CDNs
On shared HTTPS infrastructure, SNI tells the server which hostname the client wants so it can select the corresponding certificate. If the hostname is not mapped correctly, the server may present a default certificate belonging to another virtual host.
The same issue exists at higher layers. A load balancer can have one certificate attached to the wrong listener, or a CDN can serve its own edge certificate while the origin has a different, perfectly valid certificate. Fix the certificate where the public TLS connection terminates.
Step 6: reissue or redeploy with the right names
If the requested hostname is genuinely missing, reissue the certificate with the required SAN entries or use an appropriate wildcard plus any uncovered apex names. Then deploy the certificate to every TLS termination point that can receive traffic.
After deployment, test the exact failing hostname again. Also test alternate public names such as www, apex, API or shop subdomains individually rather than assuming one successful hostname proves the whole certificate configuration.
Do not “fix” a mismatch by disabling certificate verification
Hostname verification protects clients from accepting a valid certificate for the wrong service. Disabling verification, ignoring browser warnings or forcing clients to trust a mismatched certificate removes an important identity check. Correct the certificate coverage or routing instead.
What Smart Web Utility can and cannot prove
The SSL Checker can confirm a successful verified TLS connection and, when verification succeeds, show certificate SANs and endpoint details. Because it enforces certificate verification, a severe mismatch may stop the connection before the tool can display every field from the invalid certificate. It also checks one resolved endpoint per request rather than auditing every edge node worldwide.
Frequently asked questions
Does a wildcard certificate cover the root domain?
No. *.example.com does not identify example.com. Include the apex separately when the site serves it.
Can I fix a hostname mismatch with a redirect?
Not for an HTTPS request to the mismatched hostname. TLS validation happens before the browser can receive the HTTP redirect, so the original HTTPS hostname still needs valid certificate coverage.
Why does the certificate match on one server but not for users?
Users may be reaching a CDN, load balancer, different A/AAAA target or another node that presents a different certificate.
What does NET::ERR_CERT_COMMON_NAME_INVALID usually indicate?
It commonly appears when the requested hostname is not covered by the certificate the browser receives. Modern standards rely on SAN DNS identities rather than the legacy Common Name for service identity matching.