ERR_CERT_COMMON_NAME_INVALID: How to Fix It on Chrome, Edge, Firefox, NGINX, Apache, and Cloudflare

by

ERR_CERT_COMMON_NAME_INVALID means the SSL certificate presented by the website does not match the hostname in the browser address bar. In simple terms, the browser asked for one domain, but the server replied with a certificate for a different name.

This error is common on new domains, misconfigured subdomains, reverse proxy setups, Cloudflare zones, and servers that serve the wrong certificate on port 443. The fix is usually practical: correct the hostname, certificate coverage, or HTTPS routing.

Quick Fix

  • Check the exact URL in the address bar.
  • Try the site with and without www.
  • If you own the site, confirm the SSL certificate covers the hostname you are opening.
  • If you use Cloudflare, make sure the DNS record is proxied, not DNS-only.
  • Verify whether the subdomain is first-level or second-level.
  • Check whether the certificate is active and not expired.
  • Test the site in another browser and on another device.
  • Clear browser cache and restart the browser.
  • Disable VPN, proxy, or antivirus HTTPS scanning temporarily.
  • Run an external SSL test to see which certificate the server is actually presenting.

What Is ERR_CERT_COMMON_NAME_INVALID?

ERR_CERT_COMMON_NAME_INVALID is a browser SSL error. It appears when the certificate returned during the HTTPS handshake does not match the domain name the visitor tried to open.

For example, if a visitor opens https://www.example.com but the server presents a certificate only valid for example.com, the browser may block the connection. The same problem happens when a subdomain, proxy, CDN, or reverse proxy points traffic to the wrong certificate. Cloudflare documents this error directly and notes that hostname coverage, proxy status, second-level subdomains, and SNI support are common factors. :contentReference[oaicite:1]{index=1}

Modern browsers do not trust a certificate just because it is valid and unexpired. It also has to match the hostname exactly or through a supported wildcard pattern.

This error often appears in these situations:

  • The certificate covers example.com but not www.example.com.
  • The certificate covers the main domain but not a subdomain like blog.example.com.
  • A second-level subdomain such as dev.www.example.com is not covered by the default certificate.
  • The site is behind Cloudflare, but the DNS record is not proxied.
  • The wrong certificate is being served by Apache, NGINX, or a load balancer.
  • A visitor is using an outdated browser without SNI support.

Why ERR_CERT_COMMON_NAME_INVALID Happens

Most real cases come from a short list of SSL configuration mistakes.

1. The Certificate Does Not Cover the Hostname

This is the main cause. The certificate was issued for one domain name, but the visitor opened another.

Common examples:

  • example.com works, but www.example.com does not.
  • shop.example.com is missing from the certificate.
  • A wildcard certificate covers *.example.com but not the apex domain example.com.
  • A second-level subdomain like dev.www.example.com is outside the default coverage.

Cloudflare explicitly notes that Universal SSL covers the apex domain and one level of subdomains, but not second-level subdomains such as dev.www.example.com unless you use an advanced certificate, custom certificate, or Total TLS. :contentReference[oaicite:2]{index=2}

2. The Wrong Certificate Is Served

The right certificate may exist on the server, but the wrong one is being presented to the browser.

This happens often when:

  • Several sites share one server or IP address.
  • The default HTTPS virtual host is wrong.
  • NGINX or Apache is using the wrong server block.
  • A reverse proxy sends traffic to the wrong backend.

3. Cloudflare Proxy Status Is Wrong

If you use Cloudflare, the hostname usually needs to be proxied for Cloudflare edge certificates to apply. Cloudflare’s docs state that SSL/TLS certificates only apply to traffic proxied through Cloudflare, and they specifically recommend ensuring the hostname is set to proxied when troubleshooting NET::ERR_CERT_COMMON_NAME_INVALID. :contentReference[oaicite:3]{index=3}

If a DNS record is set to DNS-only, the browser may hit your origin directly. If the origin certificate is missing, outdated, or for the wrong hostname, the browser will show a name mismatch error.

4. The Universal SSL Certificate Is Not Active Yet

New domains behind Cloudflare do not always get their edge certificate instantly. Cloudflare states that certificate provisioning can take from 15 minutes to 24 hours, and during that period visitors may see SSL errors. :contentReference[oaicite:4]{index=4}

This is common when:

  • You just added the domain to Cloudflare.
  • You changed nameservers recently.
  • The domain was flagged for extra review by the certificate vendor.

5. The Browser Does Not Support SNI

Cloudflare Universal SSL relies on SNI. Cloudflare notes that older browsers without SNI support may show certificate-related SSL errors even when the site is configured correctly for modern clients. :contentReference[oaicite:5]{index=5}

This is far less common today, but it still matters for very old devices, legacy systems, or embedded browsers.

6. The Site Uses the Wrong URL Canonical Form

Sometimes the certificate is fine for one hostname, but users are being redirected or linked to another hostname that is not covered.

Examples:

  • The certificate covers example.com, but the site forces www.example.com.
  • The admin panel redirects to an internal hostname.
  • A staging domain was left in configuration files.

7. Antivirus, Proxy, or VPN Software Intercepts HTTPS

Not every mismatch is on the server. Local HTTPS inspection can replace or rewrite certificates. If that local software does it badly, the browser may report a certificate name mismatch on one machine while the same site works everywhere else.

How to Fix ERR_CERT_COMMON_NAME_INVALID Step by Step

Start with the hostname. Then check certificate coverage, proxy layers, and server configuration.

1. Check the Exact Domain in the Address Bar

This sounds basic, but it solves a surprising number of cases.

  • Look for typos.
  • Check whether you opened www or non-www.
  • Check whether the link points to a subdomain.
  • Make sure you are not opening a staging or internal hostname by mistake.

If one hostname works and another does not, the issue is probably certificate coverage or redirect logic.

2. Test the Site With and Without WWW

Many SSL mismatches are simply www problems.

Try both:

  • https://example.com
  • https://www.example.com

If only one version works, the certificate or redirect setup is incomplete.

3. Check the Certificate Details in the Browser

Open the certificate viewer and inspect the names listed in the certificate.

Look for:

  • Common Name
  • Subject Alternative Names (SANs)
  • Issuer
  • Expiration date

The most important part is hostname coverage. If the domain you opened is not listed there, the browser is correct to block it.

4. Confirm the Certificate Covers the Hostname

If you own the site, verify the exact names on the certificate.

Check these combinations carefully:

  • example.com
  • www.example.com
  • blog.example.com
  • api.example.com
  • Any staging or panel hostnames

Do not assume a wildcard covers everything. A wildcard such as *.example.com normally covers one level of subdomains, not deeper levels, and not always the apex domain itself.

5. If You Use Cloudflare, Make Sure the Record Is Proxied

Cloudflare specifically advises that the hostname should be set to proxied when troubleshooting NET::ERR_CERT_COMMON_NAME_INVALID. If the record is DNS-only, the origin server certificate becomes the one the visitor sees. :contentReference[oaicite:6]{index=6}

Check:

  • Whether the hostname has the orange cloud enabled.
  • Whether only some subdomains are proxied.
  • Whether the failing hostname bypasses Cloudflare entirely.

6. Check Whether the Hostname Is a Second-Level Subdomain

This matters a lot on Cloudflare. Cloudflare documents that Universal SSL covers the root domain and one level of subdomains, but not second-level subdomains like dev.www.example.com. For those, Cloudflare recommends an advanced certificate, a custom certificate, or Total TLS. :contentReference[oaicite:7]{index=7}

If your failing hostname has two dots before the main domain, check this first.

7. Wait for Edge Certificate Provisioning if the Domain Is New

If you recently enabled Cloudflare or added a new hostname, the certificate may not be ready yet. Cloudflare says this process can take 15 minutes to 24 hours. :contentReference[oaicite:8]{index=8}

If the domain is brand new:

  • Check the Edge Certificates section.
  • Confirm whether a Universal certificate is active.
  • Avoid changing multiple SSL settings at once while waiting.

8. Verify Apache HTTPS Virtual Host Configuration

If the site is on Apache, make sure the domain is using the correct SSL virtual host.

A minimal example looks like this:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/fullchain.pem
    SSLCertificateKeyFile /path/to/privkey.pem
</VirtualHost>

Check for:

  • Wrong ServerName
  • Missing ServerAlias
  • Wrong certificate path
  • Wrong key path
  • The wrong site handling HTTPS requests

9. Verify NGINX HTTPS Server Block

If you use NGINX, make sure the correct certificate is attached to the correct hostname.

A minimal example looks like this:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
}

Check for:

  • Wrong server_name
  • Wrong certificate file
  • Wrong default server
  • Another server block catching the request first

10. Check Redirect Rules and Canonical URLs

A correct certificate can still fail if your redirects send users to a hostname not covered by the certificate.

Review:

  • NGINX rewrite rules
  • Apache redirects
  • Cloudflare redirect rules
  • WordPress site URL settings
  • CDN or load balancer hostname rewrites

Common example: the apex domain is covered, but the redirect sends everyone to www, which is not on the certificate.

11. Run an External SSL Test

Do not rely only on one browser error page. Use an SSL testing tool to see what certificate the site is actually serving.

Look for:

  • Hostname mismatch
  • Missing SAN entries
  • Wrong certificate chain
  • Wrong certificate on one subdomain only

This often confirms in minutes whether the server, proxy, or CDN is serving the wrong certificate.

12. Disable Local HTTPS Inspection if the Problem Is Only on One Device

If the site works everywhere except one machine, test local software.

  1. Disable VPN.
  2. Disable manual proxy.
  3. Temporarily turn off antivirus HTTPS scanning.
  4. Restart the browser.
  5. Test again.

If the problem disappears, the mismatch came from local interception rather than the actual website.

Advanced Troubleshooting

Use OpenSSL to See the Presented Certificate

Cloudflare’s troubleshooting docs suggest using openssl s_client to inspect the TLS handshake. This is useful when you need to see what certificate is actually being served for a hostname. :contentReference[oaicite:9]{index=9}

openssl s_client -connect example.com:443 -servername example.com

This helps answer key questions:

  • Which certificate is being returned?
  • Does the handshake reach Cloudflare edge or the origin?
  • Is the hostname receiving the expected certificate?

Check SNI Behavior on Multi-Site Servers

When many HTTPS sites share one IP address, the server has to present the correct certificate based on the requested hostname. If SNI handling or default host selection is wrong, the browser may get the wrong certificate.

This is common when:

  • Several domains were added quickly to one server.
  • A default SSL virtual host catches unmatched requests.
  • Old config files were copied and reused.

Inspect the Full Proxy Chain

If the request passes through Cloudflare, a load balancer, NGINX, Apache, and then an app server, any layer can serve or trigger the wrong hostname.

Check:

  • Cloudflare DNS record status
  • Edge certificate coverage
  • Origin certificate coverage
  • Reverse proxy upstream configuration
  • App-level redirects to internal domains

Review Recent Changes

This is one of the fastest debugging methods.

  • Did you add www recently?
  • Did you turn Cloudflare on or off?
  • Did you switch hosting?
  • Did you add a new subdomain?
  • Did you replace the certificate?

Most name mismatch errors begin right after a DNS or SSL change.

Prevention Tips

  • Always issue certificates for every hostname you actually use.
  • Include both www and non-www if both may receive traffic.
  • Document all subdomains before ordering certificates.
  • Be careful with wildcard limits.
  • Keep Cloudflare proxy status aligned with your SSL plan.
  • Check second-level subdomains before relying on Universal SSL.
  • After every DNS or SSL change, run an external SSL test.
  • Do not leave staging or internal hostnames in redirects.
  • Renew certificates early and verify deployment after renewal.

When to Contact Support

Contact your hosting provider or server admin if:

  • You cannot inspect Apache or NGINX config yourself.
  • The wrong certificate is being served and you cannot change it.
  • The site uses a complex reverse proxy or load balancer chain.

Contact Cloudflare support or check Cloudflare SSL docs if:

  • The hostname is behind Cloudflare.
  • The record may not be proxied.
  • The hostname is a second-level subdomain.
  • The Universal SSL certificate is not active after a long delay.

Focus on local device troubleshooting if:

  • The site works on other devices.
  • Only one browser fails.
  • Disabling VPN, proxy, or antivirus fixes the issue.

FAQ

What does ERR_CERT_COMMON_NAME_INVALID mean?

It means the SSL certificate presented by the website does not match the hostname in the browser address bar. The browser expected one name and received a certificate for another.

Why does ERR_CERT_COMMON_NAME_INVALID happen with WWW but not without WWW?

Because the certificate often covers only one version of the hostname. If example.com is listed on the certificate but www.example.com is not, the www version will fail.

Can Cloudflare cause ERR_CERT_COMMON_NAME_INVALID?

Yes. This can happen when the hostname is not proxied, the Universal SSL certificate is not active yet, or the hostname is a second-level subdomain not covered by Universal SSL by default. :contentReference[oaicite:10]{index=10}

Does a wildcard certificate fix ERR_CERT_COMMON_NAME_INVALID?

Sometimes. A wildcard can cover one level of subdomains, such as blog.example.com, but it may not cover deeper hostnames or the apex domain unless configured accordingly.

How do I fix ERR_CERT_COMMON_NAME_INVALID on my server?

Check the exact hostname, make sure the certificate covers it, verify the correct certificate is being served on port 443, confirm redirects are not sending users to an uncovered hostname, and test the final result with an SSL checker.

Final Thoughts

ERR_CERT_COMMON_NAME_INVALID looks technical, but the root cause is usually straightforward. The hostname in the browser does not match the hostname covered by the certificate, or the wrong certificate is being served through a CDN, reverse proxy, or web server.

Start with the URL. Then verify certificate coverage, Cloudflare proxy status, second-level subdomains, and the actual certificate served on port 443. That order solves most cases much faster than random SSL changes.

Leave a Comment