Your certificate is valid, it has not expired, yet visitors see a warning that the connection is not private. If the error code reads NET::ERR_CERT_COMMON_NAME_INVALID in Chrome or Edge, or SSL_ERROR_BAD_CERT_DOMAIN in Firefox, you have an SSL certificate name mismatch. The browser received a certificate, but it was issued for a different name than the one in the address bar.
How browsers match names
Every certificate contains a list of hostnames it is valid for, stored in the Subject Alternative Name (SAN) extension. Modern browsers check only this list; the older Common Name (CN) field is ignored for matching. When you visit shop.example.com, the browser looks for that exact name, or a wildcard that covers it, in the SAN list. If it is not there, the connection is refused with a mismatch warning.
Two matching rules catch people out:
example.comandwww.example.comare different names. A certificate for one does not cover the other unless both are listed.- A wildcard
*.example.comcovers exactly one level: it matchesshop.example.combut notexample.comitself and noteu.shop.example.com.
Step 1: Find out exactly which names the certificate covers
Before changing anything, confirm what the server is really sending. Run the domain through our SSL checker, which lists every name in the certificate and tells you whether the hostname you entered matches. From a terminal you can do the same with OpenSSL:
echo | openssl s_client -connect shop.example.com:443 -servername shop.example.com 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName(The -ext option needs OpenSSL 1.1.1 or later.) Compare the list against the exact address visitors use. The cause usually becomes obvious at this point.
Common causes and their fixes
The www or bare domain is missing
The certificate covers www.example.com but people type example.com, or the reverse. Fix: reissue the certificate with both names. Most CAs include both automatically for a single-domain certificate; with Certbot, request both explicitly:
sudo certbot --nginx -d example.com -d www.example.comThen add a 301 redirect so everyone ends up on one preferred version.
A new subdomain was added later
Someone pointed portal.example.com at the web server, but the certificate was issued months earlier without it. Fix: add the name to the certificate (reissue with the extra SAN) or issue a separate certificate for it. If you add subdomains often, a wildcard certificate may be simpler.
The wrong certificate is served on shared IP addresses
Servers hosting several HTTPS sites on one IP address rely on Server Name Indication (SNI), where the browser says which hostname it wants during the TLS handshake. If a site has no matching virtual host or binding, the server falls back to its default certificate, which belongs to a different site. Fix: make sure each hostname has its own HTTPS configuration. In Nginx, check that the server_name in the listen 443 ssl block includes the hostname. In Apache, check the ServerName and ServerAlias in the <VirtualHost *:443> block. In IIS, edit the site's HTTPS binding, set the host name and tick "Require Server Name Indication".
DNS points somewhere unexpected
The hostname resolves to a different server than you think: an old host, a parked-domain page, or a hosting provider's shared server with its own certificate. Fix: look up the A and AAAA records with a DNS lookup and confirm they point at the server holding your certificate. A forgotten AAAA (IPv6) record pointing at an old server is a classic cause of a mismatch that only some visitors see.
CDN or proxy without a certificate for that name
If the site sits behind a CDN or reverse proxy, the certificate visitors see is the one at the CDN edge, not your origin's. Fix: add the hostname to the CDN's certificate settings or let the CDN issue a managed certificate for it.
Visiting by IP address or an internal name
Browsing to https://203.0.113.10 or https://server01 will always mismatch, because public CAs do not issue certificates for internal names, and certificates for IP addresses are uncommon. Fix: use the proper domain name. For internal tools, use a real subdomain such as intranet.example.com, or an internal CA trusted by your company devices.
After the fix: verify properly
- Reload or restart the web server so it picks up the new certificate (
sudo nginx -t && sudo systemctl reload nginx, for example). - Check every hostname variant: with and without www, each subdomain, over both IPv4 and IPv6 if you can.
- Test in a private browsing window to avoid cached warnings.
- If a CDN is involved, check both the public hostname and, where applicable, the origin hostname.
What not to do
Do not tell staff or customers to click through the warning. A name mismatch looks exactly like what a visitor would see during an interception attack, so training people to ignore it undermines the whole point of HTTPS. If you also use HSTS, browsers will not even offer the option to proceed.
Key takeaways
- A name mismatch means the hostname is not in the certificate's Subject Alternative Name list.
- www and the bare domain are separate names; wildcards cover only one subdomain level.
- Check what the server actually serves before reissuing anything.
- On shared IPs, missing SNI bindings and stale DNS records are frequent hidden causes.