How to Fix ERR_CERT_COMMON_NAME_INVALID: Complete Guide

SSL & Certificate Beginner 7 min read Published July 2025

ERR_CERT_COMMON_NAME_INVALID is the Chrome error that appears when the domain name you typed in the address bar does not match the domain name listed on the site's SSL certificate. During the TLS handshake the browser checks that the requested hostname matches either the certificate's Common Name (CN) or one of its Subject Alternative Name (SAN) entries. When that match fails, Chrome blocks the connection with "Your connection is not private" and names NET::ERR_CERT_COMMON_NAME_INVALID as the cause.

The error is purely about name matching — it says nothing about whether the certificate is expired, revoked, or signed by a trusted authority. A perfectly valid, unexpired, properly chained certificate still triggers this warning if it was issued for example.com while the visitor reached www.example.com, or if the certificate lists only the apex domain and the SAN omits the www variant. This guide walks through every root cause and a complete six-step fix process.

What is ERR_CERT_COMMON_NAME_INVALID?

When your browser connects to an HTTPS URL, the server presents its SSL/TLS certificate. Chrome then verifies that the hostname in the URL — say, blog.example.com — appears in the certificate's identity fields. Historically that meant the Common Name (CN) field, but because the CN cannot hold multiple names reliably, modern browsers rely on the Subject Alternative Name (SAN) extension. Chrome checks the SAN list first and falls back to the CN only as a legacy courtesy. If the requested hostname appears in neither, the handshake is aborted and ERR_CERT_COMMON_NAME_INVALID is shown.

The distinction from sibling errors matters. ERR_CERT_AUTHORITY_INVALID is about who signed the certificate, ERR_CERT_DATE_INVALID is about expiry, while ERR_CERT_COMMON_NAME_INVALID is strictly about whether the name on the certificate matches the name you asked for. A certificate can be issued by a trusted CA, be unexpired, and serve a complete chain, yet still produce this error the moment the hostname diverges by even a single subdomain label.

Common Causes

Six root causes account for almost every occurrence of ERR_CERT_COMMON_NAME_INVALID. Identifying which one applies is the fastest route to a fix.

Step-by-Step Fix Guide

Work through these six steps in order. The first two diagnose the exact mismatch; the remaining four correct it on the server.

1. Confirm the Exact Hostname Requested

Start by reading the full hostname in the address bar, including every subdomain label and any www prefix. A mismatch as small as www.example.com versus example.com is enough to trigger the error. Then resolve DNS to see which server and certificate are actually being served:

# Resolve the hostname to an IP address
dig +short example.com
dig +short www.example.com

# If both point to the same IP, the same certificate is served for both
# and one variant may be missing from the SAN.

If the two hostnames resolve to different IPs, the second server may be serving a completely different certificate. Make sure you are diagnosing the exact hostname that produced the error.

2. Inspect the Certificate's CN and SAN Entries

Connect to the server with OpenSSL and print the certificate's subject and SAN extension. This reveals exactly which names the certificate claims to protect:

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

The -subject line shows the Common Name; the subjectAltName line lists every hostname the certificate is valid for. Compare each entry against the hostname from the address bar. If the requested name is absent from both the CN and the SAN, you have confirmed the mismatch and can move on to fixing it.

3. Resolve www Versus Non-www Mismatches

The single most common trigger is a certificate that covers only one of example.com and www.example.com. The cleanest fix is to reissue the certificate so both variants appear in the SAN. Most CAs — including Let's Encrypt — let you request both at once:

# Certbot: issue one certificate covering both variants
sudo certbot certonly --nginx \
  -d example.com -d www.example.com

If reissuing is not immediately possible, configure a server-side redirect so every visitor lands on the hostname the certificate already covers. In Nginx, redirect www to the apex:

# Nginx: redirect www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

Note that the redirect block still needs a certificate valid for www.example.com to complete the TLS handshake, so reissuing with both names is usually simpler than redirecting.

4. Reissue or Reconfigure the Certificate for the Correct Domain

If the certificate was issued for the wrong domain entirely, generate a new CSR with the correct Common Name and list every required hostname in the SAN. Modern certificates should place all names in the SAN; the CN is retained only for backward compatibility:

# Generate a private key and CSR with a SAN config
openssl req -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:blog.example.com"

Submit the CSR to your CA. Once the new certificate is issued, proceed to deploy it in Step 6. If you use a control panel or CDN, update the domain list there so the SAN includes every hostname the site answers on.

5. Correct Wildcard Certificate Scope

A wildcard certificate for *.example.com matches exactly one label of subdomain — it covers www.example.com and api.example.com but not the apex example.com and not nested hosts like api.staging.example.com. If visitors hit a name outside the wildcard scope, Chrome raises ERR_CERT_COMMON_NAME_INVALID. Fix it by adding the uncovered names to the SAN:

# Wildcard plus apex in one certificate
openssl req -newkey rsa:2048 -nodes \
  -keyout wildcard.key -out wildcard.csr \
  -subj "/CN=*.example.com" \
  -addext "subjectAltName=DNS:*.example.com,DNS:example.com"

For nested subdomains such as api.staging.example.com, either issue a separate certificate for that host or request a second wildcard *.staging.example.com. A single wildcard never spans multiple label levels.

6. Deploy the New Certificate and Verify the Fix

Install the reissued certificate and key on the server, point your web server at them, and reload. Then verify with OpenSSL that the correct names are now served:

# Install the new certificate files
sudo cp fullchain.pem /etc/ssl/certs/example.com.crt
sudo cp privkey.pem   /etc/ssl/private/example.com.key

# Reload Nginx (or Apache)
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

# Verify the hostname now matches
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null

Clear the browser cache or test in an incognito window, since Chrome caches certificate decisions for a short period. When the verify output reports Verification: OK and the page loads without a warning, the fix is complete.

Certificate Diagnostic Commands

The commands below give you a complete picture of which certificate is served, what names it claims, and where DNS points. Run them from a terminal on the machine that sees the error.

# 1. Print the full certificate the server presents, plus the verify code
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# 2. Show the subject (CN), issuer, and every SAN entry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

# 3. Decode the whole certificate with openssl x509 -text and grep the SAN
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# 4. Resolve which IP each hostname points to
dig +short example.com
dig +short www.example.com

# 5. Check which certificate is served for a specific SNI hostname
echo | openssl s_client -connect 203.0.113.10:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

# 6. Verify the hostname matches using OpenSSL's built-in check
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null

Quick Reference Table

Use this table to match a symptom to its root cause and the corresponding fix.

Symptom Cause Fix
Cert covers example.com but error on www.example.com www vs non-www mismatch; SAN missing the www variant Reissue cert including both names (Step 3)
Error appears on a subdomain not on the cert Subdomain absent from the SAN list Add the subdomain to the SAN or reissue (Step 4)
Wildcard cert fails on the apex domain *.example.com does not cover the apex Include the apex in the SAN (Step 5)
Wildcard fails on api.staging.example.com Wildcard covers only one label level Issue a separate cert or a deeper wildcard (Step 5)
Self-signed cert served on a real domain Cert generated for localhost or an IP, not the domain Obtain a CA-signed cert with the correct CN/SAN (Step 4)
New cert issued but error still appears Replacement certificate not yet deployed on the server Install and reload the new cert (Step 6)

FAQ

Does the Common Name still matter in modern browsers?

Not for matching. Chrome and every other current browser ignore the Common Name for hostname validation and rely solely on the Subject Alternative Name extension. The CN is still required on the certificate for legacy compatibility, but if a hostname is not listed in the SAN, the connection fails with ERR_CERT_COMMON_NAME_INVALID even when the CN matches. Always populate the SAN with every hostname the certificate must protect.

Why does my wildcard certificate not cover the apex domain?

A wildcard *.example.com matches exactly one DNS label, so it covers www.example.com but not example.com itself, because the apex has no label in front of it. To protect both, request a certificate whose SAN lists *.example.com and example.com together. Most CAs issue this combination in a single certificate at no extra cost.

Can I fix the error by just redirecting www to non-www?

Only partially. A redirect still requires a valid TLS handshake on the redirecting hostname before the browser follows the redirect, so the www server needs a certificate that covers www.example.com. The reliable fix is to reissue the certificate with both variants in the SAN, then add the redirect for SEO and consistency. Redirecting alone does not remove the certificate warning.

How long after deploying a new certificate does the error clear?

Almost immediately for new visitors, because the browser validates the certificate on every fresh handshake. If you still see the warning, the browser is likely caching the old certificate decision — close and reopen the tab, test in an incognito window, or wait a few minutes for the in-memory cache to expire. CDN-fronted sites may also need a purge so edge nodes serve the updated certificate.

Conclusion

ERR_CERT_COMMON_NAME_INVALID always means the same thing: the hostname in the URL does not appear in the certificate's Common Name or Subject Alternative Name list. The cause is almost always one of six — a certificate issued for the wrong domain, a www versus non-www mismatch, missing SAN entries, a self-signed cert with the wrong CN, an out-of-scope wildcard, or a new certificate that was never deployed. Work through the six steps in order: confirm the hostname, inspect the CN and SAN, resolve www mismatches, reissue for the correct domain, fix wildcard scope, and deploy and verify.

Once the error clears, keep every hostname in the SAN, cover both the apex and www variant, and automate renewal so certificates never drift out of sync with the domains your servers actually serve. A few minutes of proactive certificate hygiene prevents this warning from ever reaching your visitors.

Related Guides