All tools

Guides Certificates

ERR_CERT_COMMON_NAME_INVALID on your site

Updated 6 min read

Short answer

The name in the address bar isn’t one of the names on the certificate your server sent. Chrome checks only the certificate’s Subject Alternative Names, not its common name, since Chrome 58. Firefox calls the same problem SSL_ERROR_BAD_CERT_DOMAIN.

What to do: list the names on the certificate, then fix the cause: a missing www or subdomain, the server sending its default certificate, one address serving another certificate, or a CDN in front.

The SSL certificate checker connects from our server and lists every name the certificate covers, and says whether the domain you entered is one of them. Free, no account. Check a certificate

See which names the certificate covers

Ask the server for its certificate the way a browser does, with the name in the handshake, and print the names on it. wrong.host.badssl.com is a public test site with exactly this error:

echo | openssl s_client -connect wrong.host.badssl.com:443 \
    -servername wrong.host.badssl.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name: 
    DNS:*.badssl.com, DNS:badssl.com

A wildcard covers one label only: *.badssl.com matches wrong.badssl.com, but not wrong.host.badssl.com. OpenSSL can run the same check a browser does:

echo | openssl s_client -connect wrong.host.badssl.com:443 \
    -servername wrong.host.badssl.com \
    -verify_hostname wrong.host.badssl.com 2>&1 \
  | grep 'Verify return code'
    Verify return code: 62 (hostname mismatch)

Captured on October 24, 2026 with OpenSSL 3.6.4. On your site, use your own name in all three places. 0 (ok) means the certificate covers it; 62 (hostname mismatch) is the error the browser showed. On macOS’s bundled LibreSSL openssl, which lacks -ext, use openssl x509 -noout -text and read the Subject Alternative Name lines.

Match the cause

What you see Cause Fix
The list has example.com but not www.example.com, or the reverse The certificate was issued for one name only Add the missing name
The names belong to another site, or to your host The server sent its default certificate Fix the server block or SNI
The right names on one check, the wrong ones on the next One of the site’s addresses serves another certificate Check each address
The names belong to your CDN, or none covers a deeper subdomain A CDN or proxy answers, with its own certificate Fix it at the CDN

www or a subdomain is missing

example.com and www.example.com are two names, and a certificate covers only the names listed on it. Get a new certificate with both. With Certbot, list every name, including the ones already covered:

sudo certbot certonly --cert-name example.com \
  -d example.com -d www.example.com

With --cert-name, Certbot replaces that certificate’s list of names with the ones you give it, so “the same format can be used to expand the set of domains a certificate contains” (Certbot User Guide). Then reload the web server so it serves the new file. The same applies to any subdomain: shop.example.com needs its own entry, or a wildcard *.example.com.

The server sent its default certificate

A server that hosts several sites at one address picks the certificate by the name the browser sends in the TLS handshake (SNI). When no server block matches that name, it sends its default. nginx’s documentation describes the result: “a browser receives the default server’s certificate … regardless of the requested server name” (Configuring HTTPS servers). Apache does the same with “the first listed virtual host” for that address and port (Name-based Virtual Host Support).

You can see a default certificate by leaving the name out. With the name, letsencrypt.org’s host sends the site’s certificate; without it, the host’s own default:

echo | openssl s_client -connect letsencrypt.org:443 \
    -servername letsencrypt.org 2>/dev/null \
  | openssl x509 -noout -subject
subject=CN=letsencrypt.org
echo | openssl s_client -connect letsencrypt.org:443 \
    -noservername 2>/dev/null \
  | openssl x509 -noout -subject
subject=C=US, ST=California, L=San Francisco, O=Netlify, Inc, CN=*.netlify.app

If your site gets the default even with the right name, the server doesn’t know the name: check that nginx’s server_name or Apache’s ServerName and ServerAlias list it, in the block that listens on port 443, then reload.

One address serves a different certificate

A name with several A or AAAA records can land a visitor on any of them, and one server may still have an old or wrong certificate, often the IPv6 one. The per-address check in site still shows the old SSL certificate asks each address in turn; any line with a different serial number is the server to fix.

A CDN answers for the name

With a CDN or proxy in front, visitors get the CDN’s certificate, not yours. On Cloudflare, Universal SSL covers “the root domain (for example, example.com) and first-level subdomains (for example, www.example.com or blog.example.com)”. Deeper names such as dev.www.example.com “are not covered and will not serve a valid certificate” (Universal SSL limitations). Cloudflare’s options are an advanced certificate or uploading your own that lists the name. A record that isn’t proxied isn’t covered at all: then your own server answers, and its certificate must have the name.

Why the common name doesn’t count

Certificates carry names in two places: the old subject common name (CN) and the Subject Alternative Name (SAN) extension. Chrome stopped looking at the common name in Chrome 58 (Chrome Platform Status). Google’s explanation at the time: “the commonName is ambiguous, and because of this, support for it has been a source of security bugs” (Deprecations and removals in Chrome 58).

The standards agree. RFC 9525, the current rules for matching names in TLS, says “The Common Name RDN MUST NOT be used to identify a service”. The CA/Browser Forum’s Baseline Requirements mark the common name “NOT RECOMMENDED” and require that, if present, it repeat a SAN entry (section 7.1.2.7.2). So a certificate whose common name says www.example.com doesn’t cover www.example.com unless that name is also in its SAN list, whatever the error’s name suggests.

If only some visitors see it

Chromium’s own notes on the error list causes outside your server too (net_error_list.h): “The user is on a wireless network and is being redirected to the network’s login page”, or the operating system completed a short name with a DNS search suffix that the certificate doesn’t cover. If the checks above pass from your machine and only one visitor or office sees the error, look at their network first.

Firefox shows the same problem as SSL_ERROR_BAD_CERT_DOMAIN. NSS, the library behind it, defines it as “requested domain name does not match the server’s certificate” (SSLerrs.h), and the error page says Firefox “does not trust this site because it uses a certificate that is not valid for” the name, often listing the names it is valid for. That list tells you the fix.

Sources

All sources were checked on October 24, 2026. The command output comes from our own runs on that date.

Keep reading