NET::ERR_CERT_COMMON_NAME_INVALID: what it means and how to fix it

NET::ERR_CERT_COMMON_NAME_INVALID is Chrome’s way of saying “the SSL certificate this server presented is real, but it was not issued for the domain you are trying to visit.” The certificate itself may be valid, signed by a trusted authority, and not yet expired – none of that matters if the name inside the certificate does not match the hostname in the browser’s address bar. Chrome refuses the connection and shows the red “Your connection is not private” page. Firefox shows SSL_ERROR_BAD_CERT_DOMAIN . Safari displays “Safari can’t verify the identity of the website.”

Almost every occurrence of this error comes down to one of five specific configuration problems, and each has a specific fix. This guide walks through what the error actually means, how to confirm which of the five cases applies, and how to resolve it without creating a worse problem (like disabling certificate checks).

What the error actually means#

Every SSL certificate contains one or more hostnames it is valid for. The browser checks these names against the URL you requested. If your browser asks for https://example.com/ and the certificate only lists www.example.com , that is a mismatch, and the browser aborts the connection.

The names come from two fields in the certificate:

• Common Name (CN). The original X.509 field for the certificate’s primary subject. In the certificate details it appears as CN=example.com . This is the historical field – CAs used to issue certificates with a single CN and that was the only name the cert was valid for.
• Subject Alternative Names (SAN). A list of all the hostnames the certificate is valid for. Modern browsers ignore the Common Name entirely and only check the SAN list. If the domain you are visiting is not in SAN, the cert does not cover your request, even if the CN matches.

Chrome specifically stopped trusting the Common Name field in 2017 (Chrome 58) unless a matching SAN entry is also present. Firefox, Safari, and most other browsers have similar rules. So a certificate with CN=example.com but no SANs produces the same error as a certificate with the wrong name entirely – browsers look at SANs only.

The practical consequence: when Chrome says “common name invalid,” what it usually means is “the hostname you requested is not in this certificate’s SAN list.” The fix is almost always to get the certificate reissued with the missing name included.

Verify the mismatch in 30 seconds#

Before assuming what is wrong, confirm it. Open the site in Chrome, click the Not Secure warning in the address bar, and select Certificate is not valid. A popup appears showing the certificate details. The key fields:

• Issued to – this is the Common Name. Compare against the domain you visited.
• Subject Alternative Name – the full list of domains the cert is valid for. Expand this section.

If the domain you visited is not in the SAN list, you have confirmed the cause. The rest is about picking the right fix.

Alternative diagnostic tools if the browser does not make this easy:

# See the certificate's subject and SAN list
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

The output shows the CN on the first line and the full SAN list on the second. Every hostname the certificate covers is listed. Anything not in that list will fail the check.

For a simpler interface, SiteProbe’s SSL checker parses the same data into a readable form, including the certificate’s Common Name, the full SAN list, issue/expiry dates, issuing CA, and the full chain. If the domain you tested is not in SAN, the tool flags it directly – no manual parsing needed.

SSL Labs’ ssllabs.com/ssltest/ does the same thing with more exhaustive protocol and cipher analysis, though it takes longer to run. Either tool is fine for answering “is this domain in the cert.”

The five causes and how to fix each#

Cause 1: www vs non-www (apex) mismatch

The most common single cause. Your certificate covers www.example.com , someone visits example.com , and the cert does not include the apex. Or the reverse – cert covers example.com , visitor uses www.example.com .

This often happens because the certificate was issued for one variant when the site first went live, and then DNS was extended to cover the other variant without reissuing the cert.

How to confirm: certificate SAN list shows www.example.com but not example.com , or vice versa.

How to fix:

1. Reissue the certificate to cover both. Most CAs (including Let’s Encrypt) treat example.com and www.example.com as separate names and include both in the SAN list when you request them together. Run the renewal with both names explicitly.
2. Redirect one to the other at the server level. If you picked “www” as canonical and never want apex traffic to hit a page directly, the web server can 301-redirect example.com to www.example.com before the SSL handshake even finishes… except it cannot. The TLS handshake happens before the HTTP request, so the certificate has to be valid for the exact hostname the browser is connecting to. You cannot “redirect around” a certificate mismatch.
3. Add both DNS records and keep both certs in sync. If you deliberately keep example.com as apex and www.example.com as a separate zone (unusual), both need their own valid certificates.

For Let’s Encrypt specifically, certbot’s -d example.com -d www.example.com flag covers both in one certificate. On most managed hosts, the control panel handles both automatically as long as both are listed on the site.

Cause 2: SAN list does not include the domain in use

Broader version of cause 1 – the site is reachable at multiple hostnames (apex, www, a legacy subdomain, a branded short domain redirecting to the main domain) and the certificate only lists some of them.

Examples:

• Certificate covers example.com and www.example.com but the shop is at shop.example.com and it shares the same IP
• A marketing domain exampleco.com points to the same server but is not in the certificate
• A legacy vanity domain from 2018 still resolves and people occasionally land on it

How to confirm: the specific hostname you are hitting is not in the SAN list, but other hostnames on the same server work fine.

How to fix: reissue the certificate to include the missing hostname, or issue a separate certificate for that hostname. Which makes more sense depends on how many hostnames you have and whether they all live on the same server.

For up to ~100 hostnames, a single SAN certificate covering them all is simplest. Beyond that, consider a wildcard (see cause 3) or separate per-hostname certificates managed via SNI.

Cause 3: Wildcard certificate does not cover sub-subdomains

A wildcard like <em>.example.com covers www.example.com , shop.example.com , blog.example.com , api.example.com – every name at the second* level. What it does not cover is third-level subdomains: admin.shop.example.com , staging.blog.example.com , eu.api.example.com .

The wildcard * matches exactly one DNS label. It does not match multiple labels, and it does not match across dots.

How to confirm: the certificate’s SAN list includes *.example.com but the domain you are visiting has an extra level of subdomain (more than one dot-separated segment before example.com ).

How to fix:

1. Issue a second wildcard for the sub-sub level. A certificate with both <em>.example.com and </em>.shop.example.com covers both levels. This is the cleanest option when you have a known set of sub-sub hierarchies.
2. Issue a SAN certificate listing each sub-sub domain explicitly. Reasonable if you only have a handful of them (admin, staging, eu, us).
3. Flatten the hierarchy. If staging.shop.example.com can be renamed to staging-shop.example.com , the original wildcard covers it with no reissue needed. Often the cleanest long-term answer.

Most commercial CAs sell “multi-level wildcard” or “multi-domain wildcard” certificates that cover <em>.example.com plus </em>.*.example.com in a single issue. Let’s Encrypt requires DNS-01 challenges for wildcards but supports them natively.

Cause 4: Self-signed certificate in production

Someone generated a self-signed certificate on the server (for local testing, or because the initial setup was rushed) and it never got replaced with a real one. Browsers reject self-signed certificates in production with various errors including common-name-invalid when the self-signed cert’s CN does not match the domain.

How to confirm: the certificate’s issuer is something like CN=localhost or CN=ubuntu or the server’s hostname, not a recognized CA (DigiCert, Let’s Encrypt, Sectigo, GlobalSign, etc.).

How to fix: install a properly-issued certificate. For a hosting provider, this is usually one button in the control panel that triggers a Let’s Encrypt issuance. On your own server, the simplest path is certbot – a one-line command issues and installs the certificate for you. The how to install an SSL certificate guide walks through the full process.

Never disable certificate validation in browsers or application code to “work around” a self-signed cert on a production server. Every TLS security guarantee depends on the cert being valid; disabling the check silences the error and exposes the traffic to MITM attacks.

Cause 5: Certificate was issued before a new alias was added

Closely related to cause 2, but specifically the time-ordered version. The certificate was issued when the site only had one domain. Later, marketing added a second domain pointing at the same server. The cert was never reissued.

This happens routinely in agencies and small teams where:

• The original setup ran certbot with the domain at the time
• Automatic renewal kept the same certificate (including its original SAN list) renewing forever
• Six months later, a second domain got added to DNS and pointed to the same site
• Nobody touched the cert, so the new domain is not covered

How to confirm: the certificate is valid and from a real CA, but its SAN list stops at the domains in use when the cert was originally issued. The newly-added domain is not there.

How to fix: add the new domain to your renewal configuration and force a renewal. For Let’s Encrypt:

# Include all current domains in the reissue
certbot certonly --force-renewal -d example.com -d www.example.com -d newbrand.com -d www.newbrand.com

For managed hosting, add the new domain to the site in the control panel. Most modern panels (including Hostney) detect the addition and reissue automatically within minutes. If reissuance does not happen automatically, most panels have a “Reissue SSL” or “Renew certificate” action.

One more routine gotcha: certificates issued from Let’s Encrypt via certbot store the SAN list in the renewal config file ( /etc/letsencrypt/renewal/example.com.conf ). Editing the renewal config and then running certbot renew does not pick up changes – you need to force a fresh issuance with the full domain list to update the config.

How to read the certificate from the command line#

For anyone comfortable with the terminal, this is the fastest diagnostic:

# Full certificate details
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text

The output is dense but the sections that matter for common-name-invalid debugging:

• Subject: – shows CN=example.com (or whatever the primary name is)
• Issuer: – who issued it; real CAs vs self-signed visible here
• Not Before / Not After – validity dates
• X509v3 Subject Alternative Name: – the full list of covered hostnames

For a more targeted view:

# Just the Subject and SAN
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

# Just the validity dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

The -servername flag sends SNI (Server Name Indication) which is important on servers hosting multiple sites. Without it, the server returns the default certificate, which may not be the one associated with the hostname you care about.

If openssl output is too dense, SiteProbe’s SSL checker parses all of this into a web page: Subject, SAN list, issuer, validity, full chain, TLS versions supported, cipher suites, and graded security headers. Useful for one-off checks or when you want to send someone else a link to the results.

What not to do#

• Do not tell users to “click through” the warning. The warning is telling the truth – the cert does not cover the domain – and clicking through exposes the session to interception. Fix the certificate.
• Do not disable certificate validation in your application. Setting VERIFY_PEER=false , rejectUnauthorized: false , verify=False in Python requests, or similar flags in any HTTP client silences the error and removes every security guarantee of HTTPS. This is the single worst “workaround” and it propagates bad defaults across codebases.
• Do not add a browser exception as a permanent fix. Exceptions apply only to your browser, only to your profile, only until the exception expires. Every visitor to the site will still see the error. The cert needs to be fixed at the server.
• Do not use --insecure ( -k ) with curl in production scripts. It is useful for a one-off test to confirm “the only problem is the cert name mismatch.” It is dangerous to leave in place because it silences every future TLS problem too, including legitimate cert errors from compromised servers.

Cause diagnosis flowchart#

Quick reference for “which of the five causes applies to me”:

1. Is the cert’s SAN list empty or only has Common Name? → Cause 4 (self-signed) or a very old cert. Reissue.
2. Does SAN include the base domain but not www. , or vice versa? → Cause 1. Reissue with both.
3. Is the domain a sub-subdomain (3+ labels) and SAN has a wildcard covering only the 2nd level? → Cause 3. Multi-level wildcard or explicit SAN.
4. Does SAN include all the old domains but a recently-added domain is missing? → Cause 5. Force reissue with updated domain list.
5. None of the above – domain is just plain not in SAN? → Cause 2. Reissue with the missing name.

Other SSL errors that can look similar#

Common-name-invalid often appears alongside related SSL errors. If your page shows something slightly different, these are adjacent:

• ERR_SSL_PROTOCOL_ERROR – TLS handshake failed at a lower level than name checking. Different fix path.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH – server and browser could not agree on TLS version or cipher suite. Sometimes shown for name mismatches on very old configurations, usually means a protocol mismatch.
• This site can’t provide a secure connection – the umbrella “Chrome gave up on the SSL handshake” error; common-name-invalid is one specific cause under this umbrella.
• NET::ERR_CERT_AUTHORITY_INVALID – the certificate is signed by a CA the browser does not trust. Different cause (self-signed, private CA, missing intermediate cert); different fix.
• NET::ERR_CERT_DATE_INVALID – the cert has expired (or the client clock is wrong). Renew, or sync the clock.

Treat each one separately. The browser is usually accurate about which error it is showing.

Common mistakes#

• Adding the new hostname to DNS without reissuing the cert. DNS says “go to this server”; SSL says “the server is who you expect.” Both have to match. DNS alone is not enough.
• Renewing with certbot expecting it to pick up new domains automatically. Certbot’s renew command renews only the domains already in the renewal config. To add domains you need to force a new issuance with -d for each one.
• Forgetting the -servername flag in openssl tests. On shared-hosting or SNI-based servers, you get the default certificate instead of the one you are debugging. Always include -servername .
• Assuming “SSL certificate” means the same thing as “correct SSL certificate.” Browsers do not just check “is there a cert” – they check “is the cert valid for this hostname, issued by a trusted CA, not expired, and served with the correct chain.” Failing any one of those produces an error. Common-name-invalid is specifically failing the “valid for this hostname” check.
• Removing SAN entries when renewing. If the renewal process only includes the currently-popular domain but the site still has traffic on legacy hostnames, the legacy traffic starts failing. Keep the SAN list complete when reissuing.
• Trusting the Chrome “Continue to site” option for anything that handles credentials or payments. If the cert does not match, the TLS protection is not verifying what it is supposed to verify, and the site should be considered unauthenticated. Fix the cert before letting users through.

How Hostney handles certificate management#

Hostney issues and renews SSL certificates automatically via Let’s Encrypt for every hostname added to a site. When you add a new domain to an existing account (for example, the marketing team points a new brand domain at the same site), the platform detects the new hostname, issues a certificate that includes both the original and new domains, and deploys it to nginx without any manual step. The renewal runs automatically before expiry, so the “cert issued before the new alias was added” problem (cause 5 above) is avoided as long as the new domain is added through the control panel.

If a hostname is configured in DNS but not added to the site inside the control panel, the platform does not know about it and will not include it in the certificate. Check Hosting > Subdomains or the equivalent in your account to make sure every hostname you expect to serve HTTPS is listed there. Anything missing will produce exactly the common-name-invalid error covered in this guide until added.

For users who bring their own certificate (less common, but supported for Extended Validation certs or specific compliance requirements), the upload goes through the control panel with full chain validation before accepting it. Mismatched certs, missing intermediates, and expired certs are flagged at upload time rather than after they start serving traffic. The broader context for when a paid/EV certificate makes sense over free Let’s Encrypt is in free vs paid SSL certificates.

The tools.hostney.com/ssl checker mentioned above is the same tool used internally when support is helping diagnose a cert issue – running it against your domain produces the same detailed report the Hostney team would use to answer “is the cert right?”

Summary#

NET::ERR_CERT_COMMON_NAME_INVALID means the SSL certificate does not list the exact hostname the browser requested. Modern browsers ignore the legacy Common Name field and check only the Subject Alternative Name (SAN) list – if the domain is missing from SAN, the request fails regardless of what CN says. The five causes are: apex-vs-www mismatch (most common), any SAN missing (broader version of the first), wildcard not covering a sub-sub domain, self-signed certificate left in production, or a certificate issued before a new alias was added. The diagnostic is the same in every case – inspect the cert’s SAN list through the browser, openssl s_client , or SiteProbe’s SSL checker, identify which domain is missing, and reissue the certificate with the full list. Do not click through the warning, do not disable certificate validation in code, and do not add permanent browser exceptions – the fix always lives at the server, and usually takes one certbot command or one button click in a control panel.