Guides · TLS
Why Your New SSL Certificate Shows A Name-Mismatch Error
A certificate name-mismatch error means the hostname you connected to is not listed in the certificate's Subject Alternative Names. This guide covers the usual causes — apex vs www, wildcards, wrong cert, and half-deployed renewals — and how to confirm each.
By Cody · 7 min read · Published
The short version
A name-mismatch error does not mean your certificate is broken, expired, or untrusted. It means the certificate is valid — just issued for a different name than the one you connected to. The client compared the hostname in the URL against the certificate's Subject Alternative Names and did not find a match.
On a brand-new certificate the culprit is almost always one of four things: apex vs www, a wildcard that does not reach the name you used, the wrong certificate installed, or a renewal deployed to only some servers. Read the SAN list, compare it to your exact hostname, and the cause is right there.
What the browser is actually checking
When a client validates a certificate it checks three things independently: that the chain is trusted, that the dates are current, and that the hostname matches. A name mismatch is only the third check failing — the other two can be perfectly fine, which is why the error is so confusing on a freshly issued certificate.
Crucially, modern browsers match the hostname against the Subject Alternative Name (SAN) list and ignore the legacy Common Name entirely. So a certificate whose CN reads example.com will still be rejected for example.com if that name is not also present in the SANs. Always read the SAN list, never the CN.
The usual causes
| Cause | What you see | Fix |
|---|---|---|
| Apex vs www | Cert covers example.com, you hit www.example.com (or vice versa). | Reissue with both names, or redirect to the covered host. |
| Wildcard depth | *.example.com used for the apex or for a.b.example.com. | Add the apex / deeper name explicitly to the SANs. |
| Wrong certificate installed | SANs list a totally unrelated domain or a hosting default. | Install the correct certificate for this host. |
| Connecting by IP | URL is https://198.51.100.10; SANs contain only hostnames. | Use the hostname; check SNI on shared load balancers. |
| Half-deployed renewal | Intermittent mismatch — some nodes serve old / default cert. | Deploy the new cert to every node behind the balancer. |
The wildcard one-level rule
Wildcards trip people up because they cover exactly one label of depth — no more, no less. *.example.com matches www.example.com and api.example.com, but:
- It does not match the bare apex
example.com— that name must be listed separately. - It does not match two levels deep, like
staging.api.example.com.
So a certificate that looks correct at a glance — “it's a wildcard, it covers everything” — still throws a mismatch on the apex or on a nested subdomain. When in doubt, confirm the exact name you are using is present as its own SAN entry.
Reading it in the tools
The TLS certificate checker connects to the host and lists the certificate's Subject Alternative Names alongside the issuer, dates, and chain. Put the exact hostname from your URL next to that SAN list: if it is not there — including the www or subdomain prefix — that is your mismatch, no guessing required.
If the names look right but failures are intermittent, that points to a half-deployed renewal across nodes; and once the certificate is correct, the chain is the next thing to get right — see TLS certificate chain explained and TLS certificate expiration and troubleshooting.
Comparing the hostname to the SAN list
- Example input
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName- Example result
X509v3 Subject Alternative Name: DNS:example.com # you connected to: www.example.com # certificate covers: example.com (apex only) # -> name mismatch: www is not in the SAN list
The certificate is valid and trusted — it simply does not list www.example.com. Reissue with both example.com and www.example.com, or redirect www to the apex the certificate covers.
Related tools
FAQ
What does a certificate name-mismatch error actually mean?
It means the certificate the server presented is valid and trusted, but the hostname you asked for is not listed in it. The client compares the name in the URL against the certificate's Subject Alternative Names (SANs); if the name is not covered, it refuses the connection with errors like ERR_CERT_COMMON_NAME_INVALID or 'certificate subject name does not match target host name.' The certificate is fine — it is just for a different name.
Does the Common Name (CN) still matter?
Not to modern browsers. They validate the hostname strictly against the Subject Alternative Name list and ignore the legacy Common Name field entirely. A certificate can have the right CN and still throw a mismatch if that name is not also in the SANs. Always check the SAN list, not the CN, when diagnosing a mismatch.
Why does my certificate work for example.com but not www.example.com?
Because apex and www are two different hostnames and each must appear in the SAN list. A certificate issued for example.com does not automatically cover www.example.com, and vice versa. Either request a certificate that lists both names, or make sure the host the visitor reaches matches the name the certificate was issued for. This is the single most common cause of a new-cert mismatch.
Why doesn't my wildcard certificate cover the domain?
A wildcard covers exactly one label of depth. *.example.com matches www.example.com and api.example.com, but it does not match the bare example.com, and it does not match a.b.example.com (two levels deep). If you need the apex covered, the certificate must list example.com explicitly in addition to the wildcard. Depth mismatches like these produce a name-mismatch even though the wildcard looks right.
Why do I get a mismatch when connecting by IP address?
Certificates are issued for hostnames, not IP addresses (except in rare, specially issued IP certificates). When you connect to https://198.51.100.10 the client compares the IP against the SANs, finds only hostnames, and reports a mismatch. Connect by the hostname instead. The same thing happens behind a shared load balancer if the client does not send the correct SNI hostname.
The certificate is right but some requests still fail. Why?
Almost always a half-deployed renewal. When several servers or edge nodes sit behind a load balancer, a new certificate has to be installed on all of them. If one node still serves the old or a default certificate, a fraction of requests hit it and fail intermittently while the rest succeed. Check every node, not just the first one that answers, and confirm they all present the same new certificate.
How do I confirm which names a certificate actually covers?
Inspect the certificate and read its Subject Alternative Name list, then compare it to the exact hostname in your URL — including the www or subdomain. If the name you are using is not in the list, that is the mismatch, and the fix is to reissue the certificate with the missing name or to serve the request from a host the certificate already covers. Re-check after deploying to confirm every server presents the corrected certificate.
Last reviewed: 2026-07-08.