ERR_CERT_COMMON_NAME_INVALID: Certificate Name Mismatch

Quick reference

Error	ERR_CERT_COMMON_NAME_INVALID
Chrome text	"Your connection is not private — NET::ERR_CERT_COMMON_NAME_INVALID"
Firefox text	"Warning: Potential Security Risk Ahead"
Layer	TLS (after TCP, during certificate validation)
HTTP code?	No — browser blocks before HTTP

What ERR_CERT_COMMON_NAME_INVALID means

When a browser connects to an HTTPS URL, it performs TLS certificate validation. One required check is hostname verification: the domain in the URL must match one of the hostnames listed in the certificate. ERR_CERT_COMMON_NAME_INVALID means this check failed — the certificate presented by the server does not cover the domain name the browser is trying to reach.

Modern browsers validate against the certificate's Subject Alternative Names (SAN) extension, not the deprecated CN (Common Name) field. A certificate that lists www.example.com as its CN but has no SAN extension will fail validation in Chrome since 2017. All certificates issued by public CAs now include SAN entries.

The browser blocks the connection entirely and shows the security warning page. Users can click "Advanced" and bypass the warning (except on HSTS-preloaded sites), but this defeats the purpose of TLS and should never be a production fix.

Why hostnames do not match

Certificate issued for the wrong hostname. The certificate was issued for www.example.com but the request is to example.com (apex domain without www). These are different hostnames. The fix is to issue a certificate that covers both: a multi-SAN certificate listing both example.com and www.example.com.

Subdomain not in wildcard scope. A wildcard certificate for *.example.com covers one level of subdomains: api.example.com, www.example.com, cdn.example.com. It does not cover the apex domain example.com or sub-subdomains like api.staging.example.com. Request covers a host outside the wildcard scope: hostname mismatch.

Certificate on wrong virtual host. A server hosts multiple domains but the TLS certificate for domain A is being served to requests for domain B. This happens when Server Name Indication (SNI) is not configured — the server serves its default certificate regardless of which domain was requested.

Accessing by IP instead of hostname. Accessing https://93.184.216.34 directly. IP addresses are not covered by domain certificates. The browser shows ERR_CERT_COMMON_NAME_INVALID because the certificate lists example.com but the URL uses a raw IP.

Local development with self-signed certificate. A self-signed certificate for localhost is used to serve 127.0.0.1 directly, or a certificate issued for one local hostname is used for another. The browser sees a mismatch.

Inspecting the certificate

# Check what hostnames the server's cert covers: openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A5 "Subject Alternative Name" # Output example: # X509v3 Subject Alternative Name: # DNS:example.com, DNS:www.example.com # Check the CN (legacy field): openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject # subject=CN=example.com # Quick cert info with curl: curl -vI https://example.com 2>&1 | grep -E "subject:|issuer:|expire"

Fixes

Issue a new certificate covering all required hostnames. With Let's Encrypt:

certbot --nginx -d example.com -d www.example.com -d api.example.com # Creates a single certificate with all three as SANs

Use a wildcard certificate:

certbot certonly --dns-cloudflare -d example.com -d "*.example.com" # Wildcard requires DNS-01 challenge, not HTTP-01

Fix SNI on the web server. Ensure each virtual host has its own certificate configured, and that nginx/Apache use SNI to select the correct certificate based on the requested hostname:

# nginx — one server block per domain with its own ssl_certificate server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; } server { listen 443 ssl; server_name api.otherdomain.com; ssl_certificate /etc/letsencrypt/live/otherdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/otherdomain.com/privkey.pem; }

For local development: Use mkcert to create locally trusted certificates for development hostnames:

brew install mkcert # macOS mkcert -install # install local CA mkcert localhost 127.0.0.1 myapp.local # Creates locally trusted certs — no browser warning

ERR_CERT_COMMON_NAME_INVALID vs related errors

Error	TLS stage	Cause
ERR_CERT_COMMON_NAME_INVALID	Cert validation	Hostname not in certificate SANs
ERR_CERT_DATE_INVALID	Cert validation	Certificate expired or not yet valid
ERR_CERT_AUTHORITY_INVALID	Cert validation	Certificate not issued by trusted CA
SSL Handshake Failed	Handshake	Protocol/cipher mismatch before cert seen
Cloudflare 526	Cert validation	Same check, from Cloudflare perspective

Frequently asked questions

Does the CN field still matter for hostname validation?

No. Chrome has ignored the CN field for hostname validation since Chrome 58 (2017). Firefox followed. All validation now uses the SAN extension. A certificate with a correct CN but no SAN extension will fail hostname validation in all modern browsers. All public CAs add SAN entries automatically when issuing certificates.

Can HSTS prevent bypassing the certificate warning?

Yes. Sites with HSTS enabled (Strict-Transport-Security header) cannot be bypassed by clicking "Advanced." Sites on the HSTS preload list are hardcoded in browsers and cannot be accessed with an invalid certificate at all — not even temporarily. This makes proper certificate management critical for preloaded sites.

Why does the error occur intermittently?

Intermittent hostname mismatch often happens when multiple server instances with different certificates are load-balanced, and only some of them have the correct certificate. Or when a new certificate was partially deployed (some nginx workers reloaded, others still serve the old certificate). Force-reload all workers and verify all instances serve the same certificate.

Do certificate transparency logs help diagnose this?

Yes. crt.sh lists all certificates issued for a domain, including their SAN entries and issue dates. Search for your domain at https://crt.sh/?q=example.com to see which certificates exist, when they expire, and what hostnames they cover. This helps identify mismatched or forgotten certificates still in use.

All Guides · Home