Chrome’s NET::ERR_CERT_COMMON_NAME_INVALID error has one technical definition: the hostname in your browser’s address bar does not match any hostname in the certificate’s Subject Alternative Names field. But that single definition covers at least six completely different scenarios, each with a different root cause and a different fix.
The wrong approach is running through a checklist of generic fixes until one works. The right approach is reading the certificate that Chrome received and identifying precisely which scenario you are in. That takes two minutes and points directly to the relevant solution.
This guide is organized around the six scenarios. Start by reading the certificate, identify your scenario by name, and go directly to that section.
Step Zero: Read the Certificate Chrome Received
Every instance of this error involves a certificate being served that does not cover the hostname you requested. The first thing to do is see exactly what the certificate says, not what you think it should say.
In Chrome
- Click the Not Secure warning or lock icon in the address bar
- Click Connection is not secure
- Click Certificate is not valid
- In the certificate viewer, check two things: the Subject (who it was issued to) and the Subject Alternative Name section under the Details tab (every hostname it covers)
Via command line (the fastest method for site owners)
| # See exactly what the server is presenting:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -text | grep -A10 ‘Subject Alternative Name’
# Also useful: check the Subject field openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -subject
# Without SNI (to test default cert): openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -text | grep -A10 ‘Subject Alternative Name’
# Compare the two outputs. If they differ, SNI is selecting different certs. |
With those two outputs in front of you, match what you see to one of the six scenarios below.
The Six Scenarios at a Glance
| Scenario | What the Certificate Shows | What You Requested | Primary Fix |
| 1. Wrong domain installed | Certificate for otherdomain.com or an unrelated domain | yourdomain.com | Install the correct certificate |
| 2. Missing www / non-www | yourdomain.com only | www.yourdomain.com (or vice versa) | Reissue cert with both SANs, or fix redirect |
| 3. Uncovered subdomain | yourdomain.com or *.otherdomain.com | sub.yourdomain.com | Add SAN or get wildcard certificate |
| 4. CN-only cert (no SANs) | Subject CN: yourdomain.com, no SAN extension | yourdomain.com | Reissue certificate with SANs — Chrome requires them |
| 5. CDN serving wrong cert | Certificate for a completely different domain | yourdomain.com | Fix CDN/load balancer certificate mapping |
| 6. Local / dev environment | Certificate for localhost or machine name | 127.0.0.1, localhost, or local domain | Generate cert with correct SAN or trust it in OS store |
Scenario 1: The Wrong Certificate Is Installed
The certificate in the viewer shows a completely different domain than the one you are trying to reach. This is the most straightforward scenario. The wrong certificate file was installed during setup, or the certificate was renewed but the new file was placed in the wrong virtual host configuration.
How to confirm it
The Subject field in the certificate viewer shows a hostname that is not your domain. The SAN list, if present, contains hostnames belonging to a different site entirely.
Fix
The certificate was installed in the wrong virtual host configuration, or the server is serving a default certificate because no SNI match was found for the requested hostname. Steps:
- Verify the certificate file paths: Open your web server configuration and confirm the ssl_certificate (Nginx) or SSLCertificateFile (Apache) directive points to the correct certificate file for this virtual host.
- Confirm the server_name or ServerName: The server block or VirtualHost must include the exact hostname being requested. Nginx uses server_name; Apache uses ServerName and ServerAlias.
- Check for a default virtual host: If no SNI match exists, the server falls back to the default certificate. If a catch-all default virtual host has a different certificate, any unmatched hostname shows that certificate.
- Test after fixing: Reload the web server and use openssl s_client with -servername to confirm the correct certificate is now served.
| # Nginx: check your server blocks
grep -r ‘server_name\|ssl_certificate’ /etc/nginx/sites-enabled/
# Confirm the certificate file is correct: openssl x509 -in /path/to/your.crt -noout -subject -dates
# After fixing, reload: nginx -t && systemctl reload nginx
# Verify the fix externally: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -subject |
Scenario 2: Missing www or Non-www Version
The certificate covers yourdomain.com but not www.yourdomain.com, or vice versa. A visitor who reaches the uncovered version sees the mismatch error. The www and non-www variants are treated as separate hostnames in certificate validation. A certificate issued only for yourdomain.com does not cover www.yourdomain.com.
How to confirm it
The SAN list shows only yourdomain.com (no www prefix) and the browser is trying to reach www.yourdomain.com. Or the opposite: SAN shows www.yourdomain.com only and the visitor navigated to yourdomain.com without the prefix.
Fix A: Reissue the certificate with both variants
This is the clean long-term fix. Request a new certificate with both yourdomain.com and www.yourdomain.com as SANs. Most CAs issue certificates with both included by default when you specify one. If you are using Let’s Encrypt:
| # Certbot: include both www and non-www in the same certificate
certbot certonly –nginx -d yourdomain.com -d www.yourdomain.com
# After issuance, verify both are in the SAN list: openssl x509 -in /etc/letsencrypt/live/yourdomain.com/cert.pem -noout -text | grep -A5 ‘Subject Alternative Name’ # Should show: DNS:yourdomain.com, DNS:www.yourdomain.com |
Fix B: Redirect one version to the other before TLS terminates
If changing the certificate is not immediately possible, configure your server to redirect all traffic to a single canonical version. An HTTP-level redirect from yourdomain.com to www.yourdomain.com (or vice versa) prevents visitors from reaching the uncovered version over HTTPS. Note that this only prevents the error if the redirect happens before the TLS handshake for the uncovered version. On a server where the uncovered version shares the same IP and the same certificate, the TLS handshake fails before any HTTP redirect can be sent. A redirect only works as a fix if the covered and uncovered versions are served from separate IP addresses or configurations.
A redirect from HTTP to HTTPS does not resolve the mismatch if the certificate does not cover the hostname being accessed. The TLS handshake with the wrong hostname happens before any redirect. The redirect is only useful for ensuring visitors land on the canonical HTTPS version before the mismatch becomes visible, which requires the canonical version to have a valid certificate.
Scenario 3: A Subdomain Not Listed in the Certificate
The certificate covers yourdomain.com and www.yourdomain.com but not sub.yourdomain.com, or covers *.yourdomain.com but the visitor is trying to reach a two-level subdomain like api.v2.yourdomain.com.
How to confirm it
The SAN list shows the base domain and possibly one wildcard level, but not the specific subdomain producing the error. If the SAN shows *.yourdomain.com and the requested host is api.v2.yourdomain.com, the wildcard does not match because it covers only one subdomain label, not two.
Fix options by coverage type needed
| Situation | Best Certificate Fix |
| Specific known subdomain, no others likely to be added | Reissue the certificate with the missing subdomain added as an explicit SAN entry |
| Multiple subdomains at one level (shop., api., app., etc.) | Get a wildcard certificate (*.yourdomain.com) to cover all first-level subdomains |
| Two-level subdomain (api.v2.yourdomain.com) | Add it explicitly as a SAN or get a second wildcard (*.v2.yourdomain.com) |
| Subdomains across different base domains | Multi-domain SAN certificate listing each hostname explicitly |
| # Certbot: add a new subdomain to an existing certificate
certbot certonly –nginx -d yourdomain.com -d www.yourdomain.com -d sub.yourdomain.com
# This reissues the certificate with all three SANs. # Certbot will re-validate each domain via HTTP-01 or DNS-01.
# For a wildcard (requires DNS-01 challenge): certbot certonly –dns-cloudflare –dns-cloudflare-credentials ~/.secrets/cloudflare.ini \ -d yourdomain.com -d ‘*.yourdomain.com’
# Verify the new SANs after reissuance: openssl x509 -in /etc/letsencrypt/live/yourdomain.com/cert.pem -noout -text | grep -A10 ‘Subject Alternative Name’ |
Scenario 4: Certificate Has a Common Name but No Subject Alternative Names
This scenario catches people who generated their own certificate or used an older CA that issued certificates before SAN requirements became universal. The certificate has a Subject field showing CN=yourdomain.com but no Subject Alternative Names extension. Chrome has required SAN entries since Chrome 58 (April 2017). A certificate with only a Common Name and no SAN entries fails validation in Chrome even when the CN exactly matches the requested hostname.
Why Chrome requires SANs even when CN matches
RFC 2818 (HTTP over TLS) specifies that when a certificate has Subject Alternative Names, the Common Name must be ignored for hostname verification purposes. Chrome follows this strictly. A certificate with SANs uses only the SAN list for hostname matching. A certificate without any SANs at all fails validation in Chrome regardless of what the CN shows, because Chrome cannot use the CN as a fallback when there are no SANs to fall back from.
This matters most for self-signed certificates generated with old tools, certificates from internal CAs that have not updated their profiles, and legacy certificates issued before 2017 that were never replaced.
How to confirm it
In the certificate viewer Details tab, scroll through the extensions list. If there is no Subject Alternative Name extension at all, this is the scenario. The CN may perfectly match your domain, but the absence of SANs is the problem.
Fix: reissue with SANs explicitly included
| # For a self-signed certificate with proper SANs (development use):
openssl req -x509 -newkey rsa:2048 -keyout dev.key -out dev.crt -days 365 -nodes \ -subj ‘/CN=yourdomain.com’ \ -addext ‘subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com’
# Verify the SAN is present: openssl x509 -in dev.crt -noout -text | grep -A5 ‘Subject Alternative Name’ # Must show: DNS:yourdomain.com
# For a CA-issued certificate: request reissuance. # Submit a new CSR to your CA and request the certificate be reissued # with Subject Alternative Names explicitly listed in the certificate request. # Most modern CA issuance workflows include SANs automatically. |
Publicly trusted CAs have included SANs in all issued certificates since the CA/B Forum Baseline Requirements mandated them in 2012. If you are using a publicly trusted certificate issued after 2012 and seeing a CN-only error, the more likely cause is an extremely old cached certificate being served rather than the current certificate. Clear the SSL state in Windows (via Internet Properties, Content tab) and verify the actual certificate being served with openssl s_client.
Scenario 5: CDN or Load Balancer Serving the Wrong Certificate
The certificate being served belongs to a different domain served by the same CDN or load balancer. This happens when a CDN serves content for multiple domains from the same edge node and the certificate selection configuration is incorrect, incomplete, or the new domain was not properly provisioned.
How this happens
CDNs select which certificate to present to a visitor using SNI, the hostname the browser sends in the first TLS message. If the CDN does not have a certificate configured for the requested hostname, it falls back to a default certificate. That default certificate belongs to another domain on the same CDN account or to the CDN provider’s own wildcard certificate. The visitor’s browser sees a certificate for a completely different domain.
Load balancers with multiple HTTPS listeners have similar behavior: if the listener for a specific hostname is not configured with the correct certificate, connections for that hostname fall through to a default certificate.
Diagnosis
| # Check what certificate the CDN or load balancer is actually serving:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -subject -issuer
# If issuer shows ‘Cloudflare’ and subject shows *.yourdomain.com: # Cloudflare provisioned a certificate – check your Cloudflare SSL settings.
# If the certificate belongs to a completely different domain: # The CDN/LB is not routing your hostname to the right certificate.
# For Cloudflare: check SSL/TLS > Edge Certificates # The certificate for your domain should be Active, not Pending or Missing.
# For AWS ALB: check the Listeners configuration for HTTPS # Verify the SNI-based certificate selection includes your hostname. |
Fix by platform
- Cloudflare: Go to SSL/TLS in the Cloudflare dashboard, then Edge Certificates. Confirm a certificate covering your domain is listed as Active. If it shows Pending Validation, complete the domain verification process.
- AWS ALB: Open EC2, Load Balancers, select your ALB, go to the Listeners tab. Click the HTTPS listener, then Manage certificates. Add the certificate for your domain using the Add certificates button. ALB uses SNI to match certificates to hostnames from the listener rules.
- Nginx as reverse proxy or CDN: Add a server block for the domain with the correct ssl_certificate and server_name directives. Without a matching server_name, Nginx serves the first configured server block’s certificate as the default.
- Any CDN: Verify the domain is fully provisioned on the CDN account and that the certificate covers the exact hostname (including www vs non-www). Provisioning a new domain on a CDN often takes minutes to hours to propagate through the CDN’s certificate issuance and edge deployment process.
Scenario 6: Local Development Environment
The error appears when accessing a local development server at localhost, 127.0.0.1, or a custom local domain like myapp.local. Self-signed certificates for local development frequently cause this error for two reasons: the certificate was generated without a SAN extension (covered in Scenario 4), or the certificate was generated with localhost as the SAN but is being accessed via 127.0.0.1 or a custom hostname, or vice versa.
The IP address SAN requirement
IP addresses in certificates require a different SAN entry type than hostnames. A certificate with DNS:localhost in its SAN list does not cover 127.0.0.1, even though localhost normally resolves to 127.0.0.1. IP addresses require an iPAddress SAN entry (iPAddress:127.0.0.1) while hostnames require a DNS SAN entry. A certificate must have both if both forms of access are used.
| # Generate a development certificate covering localhost, 127.0.0.1, and ::1:
openssl req -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.crt \ -days 365 -nodes \ -subj ‘/CN=localhost’ \ -addext ‘subjectAltName=DNS:localhost,DNS:*.localhost,IP:127.0.0.1,IP:::1’
# For a custom local domain (myapp.local): openssl req -x509 -newkey rsa:2048 -keyout myapp.key -out myapp.crt \ -days 365 -nodes \ -subj ‘/CN=myapp.local’ \ -addext ‘subjectAltName=DNS:myapp.local,DNS:*.myapp.local,IP:127.0.0.1’
# Verify the SAN entries: openssl x509 -in localhost.crt -noout -text | grep -A5 ‘Subject Alternative Name’ # Should show: DNS:localhost, IP Address:127.0.0.1 |
Trusting the development certificate in the OS
Even with correct SANs, a self-signed certificate produces the ERR_CERT_AUTHORITY_INVALID error because no trusted CA signed it. For development environments, the fix is installing the certificate into your operating system’s trusted certificate store. This makes Chrome trust it because Chrome uses the OS trust store.
| # Windows: install to Trusted Root Certification Authorities
# Open mmc.exe > Certificates snap-in > Trusted Root Certification Authorities > Import # OR via PowerShell (as Administrator): Import-Certificate -FilePath .\localhost.crt -CertStoreLocation Cert:\LocalMachine\Root
# Mac: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain localhost.crt
# Linux (Debian/Ubuntu): sudo cp localhost.crt /usr/local/share/ca-certificates/localhost.crt sudo update-ca-certificates
# Alternatively, use mkcert which automates all of the above: # https://github.com/FiloSottile/mkcert mkcert -install mkcert localhost 127.0.0.1 ::1 myapp.local |
mkcert is the recommended tool for development certificates. It creates a local certificate authority, installs it into every trust store on your machine (OS, Firefox, Java), and issues certificates for any hostname you specify with correct SANs. One command produces a correctly configured certificate that Chrome trusts immediately. It eliminates every manual step described above and is the de facto standard for local HTTPS development.
When the Error Appears as a Visitor on a Working Site
If the certificate mismatch error appears only for you and other people reach the site without a problem, the cause is on your device rather than the server. Three specific issues produce this pattern.
Antivirus HTTPS inspection presenting the wrong certificate
Several antivirus products (Kaspersky, Avast, AVG, ESET, Bitdefender) include HTTPS scanning features that insert themselves between your browser and the server. The antivirus presents its own certificate to Chrome instead of the server’s actual certificate. If the antivirus certificate has the wrong hostname, incorrect SANs, or simply was not generated correctly for the site being visited, Chrome sees a certificate mismatch.
Test: open the failing site in an incognito window with all extensions disabled. If it loads, open the Chrome DevTools Network tab, click the request, and check the Security tab. If it still fails, temporarily disable your antivirus’s HTTPS scanning feature. If the error clears, the antivirus is the source. Add the affected site to the antivirus URL exclusions list.
Stale SSL state in Windows
Windows caches certificate information in an SSL state store separate from Chrome’s own cache. An outdated entry for a domain whose certificate recently changed can produce hostname mismatch errors even after the server certificate is correct. Clear it:
| # Clear Windows SSL state:
# Press Win+R, type: inetcpl.cpl, press Enter # Content tab > Clear SSL state > OK
# Then restart Chrome and retry. |
Corporate proxy or network inspection appliance
Enterprise networks often run network appliances that inspect HTTPS traffic by decrypting and re-encrypting it. If the appliance presents a certificate with incorrect hostname data, Chrome sees a mismatch. The fix requires IT department involvement: the appliance must generate certificates with correct SANs for each site it intercepts, and the appliance’s signing CA certificate must be installed in Chrome’s trusted certificate store on managed devices.
Quick Diagnosis Reference
| What the certificate shows | What you requested | Your scenario | Primary fix |
| A completely different domain | yourdomain.com | Scenario 1 | Install correct certificate in right virtual host |
| yourdomain.com only (no www) | www.yourdomain.com | Scenario 2 | Reissue with both SANs |
| www.yourdomain.com only | yourdomain.com | Scenario 2 | Reissue with both SANs |
| yourdomain.com but not sub.yourdomain.com | sub.yourdomain.com | Scenario 3 | Add subdomain to SANs or get wildcard |
| *.yourdomain.com but not api.v2.yourdomain.com | api.v2.yourdomain.com | Scenario 3 | Add explicit SAN for two-level subdomain |
| CN=yourdomain.com, no SAN extension visible | yourdomain.com | Scenario 4 | Reissue with SANs — Chrome requires them |
| A CDN provider’s default or different client cert | yourdomain.com | Scenario 5 | Provision certificate on CDN/LB for this hostname |
| Certificate for ‘localhost’ not ‘127.0.0.1’ | 127.0.0.1 | Scenario 6 | Add iPAddress:127.0.0.1 SAN; use mkcert |
| Certificate for machine name, not localhost | localhost | Scenario 6 | Regenerate dev cert with DNS:localhost SAN |
| Site works for others, only fails for you | yourdomain.com | Visitor-side | Check antivirus HTTPS scanning and clear SSL state |
Frequently Asked Questions
What does ERR_CERT_COMMON_NAME_INVALID mean?
Chrome’s NET::ERR_CERT_COMMON_NAME_INVALID error means the SSL certificate presented by the server does not contain the hostname you are trying to reach. Chrome checks the certificate’s Subject Alternative Names (SAN) field against the requested hostname and terminates the connection if no match is found. This is a certificate validation failure, not a network problem. The error can stem from a misconfigured server certificate, a CDN serving the wrong certificate, or in some cases from local antivirus software intercepting the connection and presenting its own certificate.
Why does Chrome require Subject Alternative Names? My certificate has the correct Common Name.
Chrome has required Subject Alternative Names since version 58, released in April 2017. RFC 2818 specifies that when a certificate has SAN entries, the Common Name must be ignored for hostname matching. Chrome follows this strictly and additionally requires at least one SAN entry to be present. A certificate with only a Common Name and no SAN extension will fail validation even if the CN matches the requested hostname exactly. This applies to all certificates: publicly issued, self-signed, and internally issued.
My certificate covers yourdomain.com. Why does www.yourdomain.com show the error?
The www and non-www forms of a domain are distinct hostnames in SSL certificate validation. A certificate covering yourdomain.com does not automatically cover www.yourdomain.com. The fix is reissuing the certificate with both yourdomain.com and www.yourdomain.com explicitly listed as SANs. Most modern CAs and Let’s Encrypt include both variants when you request one, but this must be confirmed in the SAN list of the issued certificate. Check the Subject Alternative Names in the certificate viewer to see exactly which hostnames are listed.
Does a wildcard certificate cover www.yourdomain.com?
Yes. The wildcard pattern *.yourdomain.com matches any single-label subdomain, which includes www. So *.yourdomain.com covers www.yourdomain.com, shop.yourdomain.com, api.yourdomain.com, and any other single-level subdomain. Most CAs also include yourdomain.com (the base domain, without any subdomain) as a separate SAN entry in wildcard certificates, but this should be confirmed in the certificate details rather than assumed.
Why does the error appear even after I renewed my SSL certificate?
Renewal and deployment are separate operations. A renewed certificate file on disk does not automatically update what the web server serves until the server is reloaded and the new file path is read. After any renewal, verify externally that the new certificate is being served using openssl s_client -connect yourdomain.com:443 -servername yourdomain.com. If it shows the old certificate, the server configuration points to the old file, the web server was not reloaded, or a CDN is caching the old certificate. Restart or reload your web server and purge any CDN cache after every certificate update.
Can I fix this error without changing the certificate?
For server-side scenarios, no. The certificate must cover the hostname being requested. There is no server-side workaround that satisfies Chrome’s validation without a correctly issued certificate covering the right hostnames. For the visitor-side scenarios (antivirus HTTPS scanning, stale Windows SSL state, corporate proxy), the fix does not require changing the server certificate. If the error appears for you but not others, start with the visitor-side checks before contacting your hosting provider.
How do I fix this for a local development environment?
Use mkcert. It is a free open-source tool that creates a local certificate authority, installs it into every trust store on your machine, and issues correctly configured certificates for any hostnames you specify. Run mkcert -install once to set up the local CA, then mkcert localhost 127.0.0.1 ::1 to generate a development certificate covering all forms of local access. Chrome trusts these certificates immediately because mkcert installs its CA into the OS trust store that Chrome uses. No manual SAN configuration, no trust store management, no ongoing errors.
