If you are seeing ERR_CERT_COMMON_NAME_INVALID, your browser is warning that the website’s SSL/TLS certificate name does not match the domain you visited.
This article explains how to fix the error on both the visitor side and the server side, so you can identify the real cause quickly.
What Does ERR_CERT_COMMON_NAME_INVALID Mean?
This browser error appears when the Common Name or Subject Alternative Name (SAN) in the certificate does not match the hostname in the address bar.
Modern browsers such as Google Chrome, Microsoft Edge, Mozilla Firefox, and Safari use this check to verify that the certificate was issued for the exact domain being requested.
For example, a certificate issued for www.example.com will not be valid for example.com unless both names are included in the certificate.
The same applies to subdomains such as app.example.com or shop.example.com.
Common Causes of the Error
Several issues can trigger this certificate mismatch.
The most common ones include:
- The certificate was issued for the wrong domain or subdomain.
- The certificate includes www but the site redirects to the non-www version, or the reverse.
- A wildcard certificate does not cover the requested hostname.
- The server is serving the wrong certificate from a multi-domain or shared hosting setup.
- A proxy, load balancer, or CDN is configured with an incorrect certificate.
- The local browser cache, DNS cache, or system time is causing certificate validation problems.
- Antivirus software or a corporate SSL inspection proxy is intercepting traffic.
How to Fix ERR CERT COMMON NAME INVALID as a Visitor
If you are not the site owner, you usually cannot repair the certificate itself, but you can rule out local causes.
Start with the browser, device, and network before assuming the website is broken.
Check the URL Carefully
Make sure the address you entered is correct.
A typo, missing subdomain, or wrong protocol can send you to a hostname that is not covered by the certificate.
Confirm whether the site expects www or the root domain.
Verify Your Device Date and Time
Incorrect system time is a common cause of SSL/TLS validation errors.
Set your operating system to use automatic time synchronization, then reload the page.
If your clock is far off, browsers may incorrectly reject an otherwise valid certificate.
Clear Browser Cache and SSL State
Browsers can store old security information.
Try clearing the browser cache and, on some systems, the SSL state.
In Chrome and Edge, closing and reopening the browser after clearing cached data can help refresh certificate checks.
Try a Different Browser or Device
If the error appears in one browser but not another, the issue may be local.
Test the same URL in Firefox, Safari, or another device on the same network.
If the certificate warning disappears, the original browser profile may be involved.
Disable VPN, Proxy, or Security Interception Temporarily
Some VPNs, corporate proxies, and endpoint security tools inspect encrypted traffic and can present their own certificates.
Temporarily disable them if policy allows, then test again.
If the error vanishes, the interception layer is likely misconfigured.
Flush DNS and Restart the Network
Stale DNS records can send you to the wrong server, especially after a site migration.
Flush your DNS cache, restart your router if needed, and reconnect.
This is particularly useful when a domain recently moved to a new host or CDN.
How to Fix ERR CERT COMMON NAME INVALID as a Site Owner
If you manage the site, the fix is usually on the server, certificate, or DNS layer.
The goal is to make sure the certificate presented by the server matches every hostname you expect visitors to use.
Confirm the Certificate Covers the Correct Hostname
Inspect the certificate details in your browser or with a tool such as openssl.
Confirm that the SAN list includes the exact domains and subdomains you serve.
For modern browsers, SAN is the most important field; the Common Name alone is no longer enough.
For sites that respond on both example.com and www.example.com, the certificate should include both names or a wildcard that truly matches the intended hostnames.
Install the Right Certificate on the Correct Virtual Host
Web servers such as Apache, Nginx, and IIS can host multiple sites on the same IP address.
If the wrong virtual host is selected, the server may present the wrong certificate.
Check your TLS configuration, hostname routing, and server name indication (SNI) settings.
On shared infrastructure, verify that each domain points to the certificate intended for that specific site.
A mismatch often occurs after a migration, a renewals process, or a manual configuration change.
Use a Certificate Issued for the Exact Domain Pattern
Choose the certificate type that fits your architecture:
- Single-domain certificate for one exact hostname.
- Multi-domain certificate for several unrelated hostnames.
- Wildcard certificate for one level of subdomains, such as *.example.com.
Remember that a wildcard certificate for *.example.com does not cover the root domain example.com and usually does not cover nested names like api.dev.example.com.
Check Redirects and Canonical Hostnames
Make sure your redirects lead users to a hostname that matches the certificate.
If the certificate is issued for www.example.com, but the site redirects to example.com, browsers will still warn users unless both hostnames are covered.
Use one canonical hostname consistently across:
- DNS records
- Web server virtual hosts
- Redirect rules
- Application settings
- Canonical tags and links
Inspect CDN, Load Balancer, and Proxy Configuration
Services like Cloudflare, AWS Application Load Balancer, Google Cloud Load Balancing, and Nginx reverse proxies can serve the wrong certificate if the configuration is incomplete.
Ensure the edge layer is configured with the correct certificate chain and that origin certificates are not exposed to public traffic unless intended.
When using a CDN, check whether the CDN is terminating TLS and whether it has the right certificate for the visitor-facing hostname.
A mismatch at the edge will appear even if the origin server is configured correctly.
Renew Expired or Misissued Certificates
Although this error is not the same as an expired certificate warning, a renewal can still install the wrong certificate if automation fails.
Reissue the certificate from your certificate authority, then verify the new certificate chain, hostname coverage, and deployment path.
Popular certificate providers include Let’s Encrypt, DigiCert, GlobalSign, and Sectigo.
If you use automated renewal tools such as Certbot, confirm the post-renewal deploy hook reloads the web server correctly.
How to Verify the Fix
After updating the certificate or configuration, test the site from multiple angles.
Open the site in a private window, on a mobile device, and from an external network if possible.
Then inspect the certificate details and confirm that the hostname matches exactly.
You can also use online SSL test tools to scan the public certificate chain and see whether the server is presenting the correct certificate for each name.
This is useful for spotting SNI issues, missing intermediates, or conflicting redirects.
Best Practices to Prevent the Error
Prevention is easier than debugging a failed certificate deployment.
Use consistent domain naming, automate certificate renewal, and test every hostname after DNS or hosting changes.
- Include every required hostname in the SAN list before issuing the certificate.
- Keep www and non-www redirects aligned with the certificate.
- Document which virtual host serves each domain.
- Monitor certificate expiration and renewal logs.
- Test staging and production separately before switching traffic.
- Verify CDN and reverse proxy certificates after each update.
For organizations with multiple environments, keep separate certificates for development, staging, and production to avoid hostname confusion.
This is especially important when internal domains, temporary preview URLs, or custom subdomains are involved.
When the Error Still Appears
If you have checked the certificate, server configuration, redirects, DNS, and local device settings, the issue may be deeper in the network path.
Common examples include stale edge caches, old certificates still active on one load balancer node, or DNS records pointing to a retired server.
In those cases, compare the certificate served from different regions or networks, then review the full path from domain registrar to DNS provider, CDN, and origin server.
The mismatch often exists in only one layer, which is why the same URL can behave differently depending on where you connect from.