ERR_CERT_COMMON_NAME_INVALID: Hostname Mismatch Fix Guide

NET::ERR_CERT_COMMON_NAME_INVALID means the certificate the server sent is valid in itself, but it was not issued for the hostname you visited. If you typed www.example.com and the certificate lists only example.com, the browser rejects it. The name in the address bar must match an entry in the certificate's Subject Alternative Name (SAN) list.

Firefox words it as SSL_ERROR_BAD_CERT_DOMAIN ("Warning: Potential Security Risk Ahead" with "the certificate is only valid for..."). Safari says the certificate is for a different name and offers to show details.

Modern browsers ignore the old Common Name field and read only the SAN extension. Chrome dropped the Common Name fallback years ago, so a certificate with the right CN but no SAN entry fails. The error name has stayed for historical reasons.

Read the exact mismatch first

Click Advanced on the warning. Chrome prints "its security certificate is from X" or lists the names. Alternatively, inspect from a terminal:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

The -ext subjectAltName option needs OpenSSL 1.1.1 or later. Compare each DNS: entry with the hostname you used. That one comparison decides everything below.

If you are a visitor

1. Check the address. A typo or a missing www can send you to a host the certificate does not cover. Try the version with and without www.
2. Use the official link. Go through the site's own homepage or an official app instead of an old bookmark or email link.
3. Check for interception. If the certificate names a router, a modem or a company you did not expect, you may be on a captive portal or a device with its own admin page. A router's setup address such as 192.168.1.1 over HTTPS will always mismatch.
4. Do not click through on sites where you sign in or pay. A mismatch is the same symptom an impersonation attempt produces.
5. Report it to the site owner with the details Chrome shows under Advanced.

If you own the site

1. The certificate lacks the hostname

The commonest cause: the certificate covers example.com but not www.example.com, or the other way round. Reissue with every name visitors use:

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com

A name must be listed even if it redirects. The browser checks the certificate before it ever sees a redirect.

2. Wildcards cover one level only

*.example.com matches www.example.com and shop.example.com, but not example.com itself and not a.b.example.com. Add the apex as a second SAN, and use a separate certificate or additional wildcard for deeper levels.

3. The server returns the wrong certificate (SNI or default vhost)

When many sites share an IP, the server selects a certificate from the name the browser sends (SNI). If the hostname is missing from every server_name or ServerName, the server falls back to its default site and sends that certificate. This happens after you point a new domain at an existing server but forget to create its virtual host.

server {
    listen 443 ssl;
    server_name shop.example.com;
    ssl_certificate     /etc/ssl/shop/fullchain.pem;
    ssl_certificate_key /etc/ssl/shop/privkey.pem;
}

Test by forcing the name:

curl -vI --resolve shop.example.com:443:203.0.113.10 https://shop.example.com/

4. DNS points at the wrong place

If the hostname resolves to a server you do not control or to a stale IP, it will present someone else's certificate. Check the A and AAAA records with the DNS Checker, then confirm who hosts that IP with the Website Hosting Checker. Look for an old IPv6 record pointing to a previous host: IPv6 users see the wrong certificate while IPv4 users do not. Dangling records are also a security risk; see subdomain takeover and dangling DNS.

5. SaaS platforms and custom domains

On website builders, e-commerce platforms and hosting panels, the platform must issue a certificate for your custom domain after DNS is verified. Until then it serves its own certificate for the platform's domain. Wait for provisioning, confirm the DNS target is exactly what the provider requests, and check for a CAA record that blocks issuance. For Shopify, see the SSL pending fix.

6. Internal names and IP addresses

Public CAs do not issue certificates for names like server1 or private IPs. For internal services use an internal CA, or give the service a real hostname.

Confirm the fix

1. Run the SSL Checker. It lists the names covered and flags a mismatch for the hostname you test.
2. Test every variant: apex, www, and each subdomain. Use the Redirect Checker to confirm that HTTP and non-canonical hostnames redirect to the main one after a valid TLS handshake.
3. Review the whole chain in the SSL Chain Debugger.

Next steps

• Read the SSL/TLS certificate errors guide for the full list of causes.
• Check the issuer side with ERR_CERT_AUTHORITY_INVALID.
• See the generic screen in Your connection is not private.
• Compare DNS answers across resolvers with the DNS Checker.

FAQ

What is the difference between Common Name and Subject Alternative Name?

The Common Name is a legacy single field; the SAN is a list of names. Browsers now rely only on the SAN, so any hostname you need must be in that list.

Why does the apex domain fail but www works?

The certificate probably lists only www.example.com. Reissue it with both names. Wildcards do not cover the bare domain.

Can I fix this on the visitor side?

No. A visitor can only confirm they typed the right address. The certificate must be reissued or the server reconfigured by the site owner.

Why does it affect only some users?

Different users may reach different servers through IPv6, CDN edges or geographic DNS, and one of them may present the wrong certificate. Test each resolved address.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.