ERR_CERT_COMMON_NAME_INVALID: Try These Proven Fixes

A customer clicks on a link to your website from Google search results. Instead of landing on your homepage, they see an error message: ERR_CERT_COMMON_NAME_INVALID. Most visitors immediately hit the ‘Back’ button—and you lose that visitor forever.

This error indicates that your browser checked the SSL certificate present on the site and found that the domain name listed on the certificate does not match the website’s actual address. This signals an identity mismatch—and browsers view this as a security threat.

The good news? Once you identify the cause, it can almost always be fixed within just a few minutes.

Quick Checks – Try These First

Try the URL with and without “www” — a minor typo here is often the most common cause.

Open the site in Incognito mode — this helps determine that the issue is not caused by browser extensions or cached data.

Check your system date and time — an incorrect clock makes valid certificates appear invalid.

Clear your browser’s cache and cookies — outdated cached certificate data generates incorrect errors.

Temporarily disable your VPN or antivirus — security tools can interfere with SSL certificates.

Run a free SSL check at ssllabs.com — instantly shows if your certificate has a domain mismatch.

What is ERR_CERT_COMMON_NAME_INVALID Error?

ERR_CERT_COMMON_NAME_INVALID is a browser SSL error that occurs when the domain name specified in a website's SSL certificate does not match the domain the user is actually visiting. The browser is unable to verify the site's identity; therefore, it blocks the connection and displays a security warning.

Every SSL certificate contains a “Common Name” (CN) field, which clearly indicates the specific domain for which the certificate was issued. If you visit www.example.com, but the certificate is valid only for example.com, the browser detects this mismatch and displays an error.

You may also see this as NET::ERR_CERT_COMMON_NAME_INVALID, SSL_ERROR_BAD_CERT_DOMAIN (Firefox), or “Safari cannot verify the identity of the website.” All of these point to the same underlying issue.

Why Does This Happen?

• www vs. non-www mismatch — certificate covers example.com but not www.example.com, or vice versa.
• Wrong Domain on Certificate — The SSL certificate was issued for a different domain, whereas access is being attempted for another domain.
• Missing Subject Alternative Names (SANs) — Subdomains or additional domains that are not listed in the certificate’s SAN field.
• Self-signed certificate — browsers don’t trust self-generated certificates on public websites.
• HTTPS enabled without SSL installed — WordPress or other CMS set to HTTPS with no actual certificate on the server.
• Incorrect HTTPS Redirects — Server redirects point to an insecure or incorrect URL variation.
• Corrupted browser cache or SSL state — old, stale certificate data causes false mismatch errors.
• Antivirus or VPN interference — security tools replace the site’s certificate with their own, causing a mismatch.

Step By Step Fixes For ERR_CERT_COMMON_NAME_INVALID

1. Try the URL With and Without “www”

The most common cause of this error is a simple mismatch between the www and non-www versions. It is possible that your SSL certificate covers only one version of your domain.

• If you see the error on www.example.com, try visiting example.com instead (without www).
• If one version loads fine, the SSL certificate isn’t covering both variations.
• As a site owner, reissue your SSL certificate with both example.com and www.example.com listed in the SAN field.

Wrong – Certificate cover only one variation

Common Name: example.com
SAN: example.com

Correct — certificate covers both www and non-www

Common Name: example.com
SAN: example.com, www.example.com

2. Run an SSL Check to Diagnose the Mismatch

Before making any changes, ensure that you identify exactly what is wrong with your certificate. A free SSL checker can reveal the precise mismatch within the domain in just a few seconds.

• Go to ssllabs.com/ssltest and enter your domain name.
• Look at the “Common Name” and “Subject Alternative Names” fields in the results.
• Compare these with the URL your visitors actually use — any difference is the cause of the error.

3. Clear Browser Cache and SSL State

Your browser caches SSL certificate data to speed up performance. If you have recently updated your certificate, the browser may still be using the old, mismatched certificate stored in its cache.

• In Chrome: Click the three-dot menu → Settings → Privacy and security → Clear browsing data.
• Select Cached images and files and Cookies → click Clear data.
• On Windows: Open Internet Options → Content tab → Clear SSL State → click OK.
• Restart Chrome and revisit the site.

4. WordPress Site URL Settings

WordPress users often switch to HTTPS within the dashboard but forget to update the Site URL—or the database URLs continue to point to the incorrect domain version, creating a mismatch.

• Go to WordPress Dashboard → Settings → General.
• Check both WordPress Address (URL) and Site Address (URL).
• Both must exactly match — same protocol (https://) and same www or non-www format.

Wrong – www and non-www settings

WordPress Address: https://example.com
Site Address: https://www.example.com

Correct — both URLs must be identical

WordPress Address: https://www.example.com
Site Address: https://www.example.com

5. Reissue the SSL Certificate for the Correct Domain

If the SSL certificate was actually issued for a different domain or subdomain, clearing the cache will not resolve the issue. You will need to obtain a new certificate for the correct domain.

• Log in to your hosting control panel or SSL provider dashboard.
• Reissue the certificate and make sure the domain you enter exactly matches your live URL.
• Install the new certificate and restart your web server.

⚠ Warning: Free SSL via Let’s Encrypt is an excellent option — if configured correctly, it automatically covers both www and non-www versions.

6. Add Missing Subdomains to SAN 

If your site uses subdomains (such as blog.example.com, shop.example.com), each of them must be listed in the SSL certificate’s SAN field—otherwise, you will need a wildcard certificate.

• Check your certificate SAN field using the SSL Labs checker from FIX 02.
• If the subdomains do not exist, reissue the certificate and add them to the SAN list.
• Alternatively, get a wildcard certificate (*.example.com) to cover all subdomains automatically.

7. Incorrect HTTPS Redirects on Your Server

A redirect that sends visitors from an HTTP to an incorrect HTTPS URL can cause this error. This often occurs after a domain migration or a server change.

• Open your server’s .htaccess file
• Check that the HTTPS redirect points to the exact domain your SSL is issued for.
• Update the redirect rule if the target URL doesn’t match the certificate’s Common Name.

Correct Redirect

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

8. Disable Extensions, VPN, or Antivirus Temporarily

Some browser extensions and security software intercept HTTPS connections and replace them with their own certificates—which your browser then flags as a mismatch.

• Open the site in Chrome’s Incognito mode (extensions are disabled by default in this mode).
• If it loads fine, go to chrome://extensions and disable them one at a time.
• If Incognito also fails, temporarily disable your VPN and antivirus and reload the page.

⚠ Warning: Only disable antivirus briefly for testing. Re-enable it immediately after.

9. Sync Your System Date and Time

Browsers compare the validity dates of certificates against your computer’s clock. If the system clock is incorrect, even a valid certificate may appear to be expired or mismatched.

• On Windows: Right-click the clock → Adjust date/time → enable Set time automatically.
• On Mac: Go to System Settings → General → Date & Time → enable Set automatically.
• Reload the page after syncing.

10. Replace a Self-Signed Certificate With a Trusted One

If your site uses a ‘self-signed certificate’ (which is common in local development), all major browsers will reject it on a public website—there are no exceptions.

• Get a free trusted certificate from Let’s Encrypt via your hosting panel (most hosts support one-click install).
• Or purchase a certificate from a trusted CA like Comodo, DigiCert, or Sectigo.
• Install it, remove the self-signed cert, and restart your server.

How to Prevent This Error

• When ordering an SSL certificate, always include both the www and non-www versions in its SAN field.
• Use a wildcard certificate (*.yourdomain.com) if you run multiple subdomains.
• Never switch WordPress to HTTPS before your SSL certificate is installed and active.
• Set up auto-renewal for your SSL certificate so that it never expires without you noticing.
• After any domain migration, run an SSL check immediately to catch any mismatches as soon as possible.
• Keep your browser and OS updated — outdated software will not recognize new certificate configurations.

Best Practices

Immediately after any SSL installation, use SSL Labs' free SSL Server Test (ssllabs.com/ssltest). It grades your certificate and flags domain mismatches, missing SANs, and chain-related issues—all in a single scan.

When ordering SSL certificates, always enter your domain in both formats. Most certificate providers let you add SANs during checkout — don't skip this step. A SAN-enabled cert costs the same but covers far more cases.

For WordPress sites, install the 'Really Simple SSL' plugin after activating your certificate. It automatically fixes mixed content, updates WordPress URLs, and sets up the correct HTTPS redirects—instantly resolving 80% of SSL errors.

Frequently Asked Questions