LiveChat 
Support 
net::ERR_CERT_COMMON_NAME_INVALID: What It Means and How to Fix It
You typed a perfectly normal web address, hit Enter, and the browser slammed a full-page warning in front of you: net::err_cert_common_name_invalid. The page is blocked, the padlock is gone, and the message hints that something is wrong with the site’s security. Take a breath. This error is far less alarming than it looks, and once you understand what the browser is actually complaining about, the fix is usually straightforward.
Let me walk you through it the way I’d talk a friend through it on the phone: calmly, one step at a time.
Key Takeaways
• net::err_cert_common_name_invalid means the domain you visited does NOT match any name listed on the SSL certificate. The browser can’t confirm the certificate actually belongs to this site, so it refuses to load it.
• The encryption itself is fine. This is a *name-matching* problem, not a broken-padlock problem.
• Modern browsers check the certificate’s Subject Alternative Name (SAN) list, not the old “Common Name” field. If the exact hostname you typed isn’t in the SAN, you get this error.
• Most cases trace back to www vs. non-www mismatches, visiting a site by IP address, or a certificate issued for the wrong domain.
• If you’re the site owner, the fix is almost always to reissue the certificate covering every hostname users actually visit (or use a wildcard) and set up a www↔non-www redirect.
What does net::err_cert_common_name_invalid actually mean?
In plain language: the address in your browser bar does not match any of the names the SSL certificate says it’s valid for.
When you connect to a website over HTTPS, the server hands your browser a digital certificate. That certificate is essentially an ID card. It says, “I am the legitimate certificate for these specific domain names.” Your browser then does a simple but critical check — it compares the hostname you typed (say, `shop.example.com`) against the list of names printed on that ID card.
If the name you visited is on the list, the connection proceeds and you see the padlock. If it isn’t, the browser stops cold and shows net::err_cert_common_name_invalid. It isn’t saying the certificate is fake or expired. It’s saying, “This ID card is valid, but it belongs to a *different* name than the one you asked for, so I can’t trust that it’s really for this site.”
That distinction matters, because it tells you where to look. You’re not hunting a broken certificate. You’re hunting a name mismatch.
How does certificate name matching actually work?
Here’s the part most people — and even some developers — get wrong, and it’s the key to understanding this whole error.
Years ago, certificates identified themselves through a field called the Common Name (CN). A certificate’s CN might read `www.example.com`, and browsers checked the hostname against it. That’s where the word “common name” in the error message comes from — it’s a historical leftover.
But browsers stopped trusting the Common Name field for hostname matching. Modern browsers ignore the legacy CN entirely and check only the Subject Alternative Name (SAN) field. The SAN is a list inside the certificate that explicitly enumerates every valid hostname: `example.com`, `www.example.com`, `shop.example.com`, and so on. The hostname you visit *must* appear in that SAN list. If it doesn’t, the certificate is treated as invalid for that address — full stop.
This is the subtlety that trips people up, so let me state it directly: this error is almost never about encryption being broken. The secure, encrypted connection works perfectly fine. The certificate just doesn’t *list* the exact name you typed. And because browsers now read only the SAN — not the old Common Name — a certificate can look completely correct in its CN field and *still* throw this error if the visited hostname is missing from the SAN. So the fix is always the same in spirit: make sure every hostname users actually visit — www and non-www, and every subdomain — is included in the certificate’s SAN. Usually that means reissuing with all the names, or using a wildcard certificate that covers an entire subdomain space at once. Once you internalize that, this error stops being mysterious. If you want the deeper background on how certificates establish trust, see the complete guide to how HTTPS encryption and trust work.
What commonly causes net::err_cert_common_name_invalid?
In my experience troubleshooting these, nearly every case falls into one of a handful of patterns:
- Certificate issued for www but you visited non-www (or vice versa). A certificate covering `www.example.com` but not `example.com` will fail the moment someone drops the “www.” This is the single most common cause.
- Certificate issued for the wrong domain. During setup, the certificate was generated for a different domain than the one now being served — easy to do when juggling multiple sites.
- Accessing the site by IP address or server hostname. If you visit `https://203.0.113.10` or `https://server47.hostingprovider.net` instead of the actual domain, the certificate won’t list that IP or hostname, and the check fails.
- A shared-hosting default certificate is showing. Before your real certificate is installed and active, the server may present a generic placeholder certificate that names the host, not your domain.
- A certificate was renewed or replaced incorrectly. An expired certificate got swapped, but the replacement was scoped to fewer names than the original.
- A missing SAN entry. The certificate covers most of your hostnames but someone forgot to include a particular subdomain.
- A CDN or proxy is serving the wrong certificate. When a content delivery network or reverse proxy sits in front of your site, it may present its own certificate that doesn’t yet include your hostname.
Notice the thread running through all of these: a name that’s being *requested* isn’t a name the certificate *covers*.
How do I fix net::err_cert_common_name_invalid? (Step by step)
Work through these in order. The first two help anyone; the rest are for the person who controls the site.
- Confirm the URL and domain you typed. Look closely at the address bar. Did you visit by IP address? By the server’s hostname? With or without `www`? Try the canonical version of the site (for most sites, that’s `https://www.yourdomain.com` or `https://yourdomain.com`). If switching between www and non-www makes the error disappear, you’ve found the culprit — and the owner needs to fix the certificate or redirect.
- Don’t access the site by IP address or server hostname. Certificates are issued for domain names, not raw IPs. Visiting `https://203.0.113.10` will always fail this check. Use the real domain name instead.
- (Owner) Reissue the certificate with ALL the names you need. This is the core fix. When you request or renew the certificate, include every hostname people actually use: both `www.yourdomain.com` and `yourdomain.com`, plus any subdomains like `shop.` or `blog.`. For broad subdomain coverage, a wildcard certificate (`*.yourdomain.com`) handles every subdomain in one go.
- (Owner) Make sure the SAN covers exactly what users visit. After issuing, inspect the certificate’s Subject Alternative Name list and confirm the precise hostnames are there. Remember: browsers read the SAN, not the Common Name. A correct-looking CN is not enough.
- (Owner) Set up a www↔non-www redirect. Even with both names on the certificate, pick one canonical version and redirect the other to it. This keeps users on a consistent address and avoids duplicate-content and mismatch issues down the line.
- (Owner) Reinstall the correct certificate. If the wrong certificate is being served — a default placeholder, an old one, or one for another domain — install the right one for this site and restart the web server so it takes effect.
- (Owner) Check your CDN or proxy layer. If a CDN or reverse proxy fronts your site, add your hostname to its certificate configuration so it stops presenting a mismatched certificate.
- Clear your browser cache and the SSL state. Browsers cache certificates. After a fix is deployed, an old cached certificate can keep showing the error. Clear the cache, try an incognito window, or restart the browser to confirm the fix actually worked.
Cause-to-fix reference table
| Cause | Fix |
|---|---|
| Certificate covers www but you visited non-www (or vice versa) | Reissue covering both names; add a www↔non-www redirect |
| Certificate issued for the wrong domain | Reinstall the correct certificate for this domain |
| Accessing the site by IP address or server hostname | Visit the real domain name instead |
| Shared-hosting default/placeholder certificate showing | Install and activate your domain’s certificate |
| Certificate renewed/replaced with fewer names | Reissue with the full set of hostnames |
| A specific subdomain missing from the SAN | Add the subdomain to the SAN, or use a wildcard certificate |
| CDN/proxy serving its own mismatched certificate | Add your hostname to the CDN/proxy certificate config |
| Old certificate cached in the browser | Clear cache; test in incognito or after a restart |
Is net::err_cert_common_name_invalid a security risk?
For a legitimate site you trust that’s misconfigured, no — your data isn’t being exposed. The encryption is intact; the browser is simply being strict about verifying *which* site the certificate belongs to. That strictness is a good thing: it’s the same check that protects you from impostor sites trying to pass off the wrong certificate.
That said, never click “proceed anyway” on a site where you’ll enter a password, payment details, or any sensitive information *unless* you’re certain it’s a known site with a known misconfiguration. If you weren’t expecting the error and don’t control the site, the safest move is to back out and verify the address through another channel.
This error is a close cousin of other certificate warnings you may have seen, and the diagnostic mindset is the same across all of them.
Skip the name-mismatch headache entirely with DarazHost
Here’s the good news for anyone tired of wrestling with certificate scopes: you can avoid this error almost entirely with the right hosting setup. DarazHost’s free AutoSSL automatically issues certificates that cover your domain and its common variants — both www and non-www — with the correct SAN entries built in. That means the most common trigger for net::err_cert_common_name_invalid simply doesn’t happen on your site.
Need to cover a stack of subdomains like `shop.`, `blog.`, and `app.`? DarazHost supports wildcard SSL, so every subdomain is included under one certificate without you tracking names by hand. You get correctly-scoped HTTPS out of the box, and if you ever need to add an extra hostname, our 24/7 support team will wire it into your certificate for you. Properly named certificates, no mismatch errors, no guesswork.
How do I add a subdomain to an existing certificate?
You don’t “add” a name to a certificate that’s already been issued — certificates are immutable once signed. Instead, you reissue the certificate with the expanded list of names, then install the new one. If you anticipate adding many subdomains over time, that’s exactly the situation a wildcard certificate is built for, since it covers any subdomain of your domain automatically.
Frequently asked questions
Does this error mean my connection isn’t encrypted? No. The connection is encrypted and secure. The browser is blocking it purely because the hostname you visited isn’t listed on the certificate. It’s a naming problem, not an encryption problem.
Why does the error mention “common name” if browsers ignore the Common Name? The error name is a historical leftover from when browsers did check the Common Name field. Today the actual check happens against the Subject Alternative Name (SAN) list, but the error message kept its old label.
Will adding “www” or removing it fix the error? Sometimes, yes. If the certificate covers one form but not the other, switching to the covered version makes the error vanish. But that’s a workaround — the real fix is for the site owner to make sure both forms are on the certificate.
Can I just click “proceed anyway”? You can, but only do it on a site you trust and recognize, and never while entering sensitive data. The warning exists to protect you from certificates that don’t match the site you intended to reach.
How long does fixing it take if I own the site? Reissuing and installing a correctly-scoped certificate is usually quick — often minutes with automated SSL. The main delay is browser caching, which a cache clear or incognito test resolves.
The calm bottom line
net::err_cert_common_name_invalid looks scary but says something simple: the name you visited isn’t on the certificate. Encryption is fine; the certificate just doesn’t list your exact hostname — and because browsers now read only the SAN, the cure is always to make sure every hostname users actually visit lives in that SAN. Confirm your URL, avoid IP-address access, and if you own the site, reissue with all your names (or a wildcard) and add a www↔non-www redirect. Methodical beats panicked every time.
