NET::ERR_CERT_COMMON_NAME_INVALID

What this error means & how to recognize it

• Chrome or Edge displays “Your connection is not private” with NET::ERR_CERT_COMMON_NAME_INVALID.
• The certificate details show a Common Name or Subject Alternative Name for a different hostname.
• The bare domain works, but a particular subdomain fails.
• The error starts after adding a subdomain, changing DNS, moving hosting, or enabling a CDN or load balancer.
• A shared server or CDN presents a default, placeholder, or unrelated certificate.
• Some users or networks see the error while others do not, often indicating different IPv4, IPv6, DNS, or edge-routing paths.

Root causes, ordered by likelihood

1. The certificate does not include the requested hostname. The failing hostname may be absent from the certificate’s SAN list. A wildcard can cover some subdomains, but its scope must match the requested name.
2. The server is serving its default certificate. Shared hosting may not have the certificate assigned to the domain, or SNI and HTTPS virtual-host selection may be incorrect.
3. A CDN or load balancer has the wrong edge certificate. The hostname may not be configured on the service, or the request may reach a default listener or edge configuration.
4. DNS points to the wrong endpoint. An incorrect A, AAAA, or CNAME record can send the request to a server that presents a certificate for another site. An incorrect AAAA record can affect IPv6 users even when IPv4 works.
5. A migration or domain change left services out of sync. DNS, the CDN, origin server, and certificate may each be configured for different hostnames or endpoints.

How to fix it

1. Identify the exact hostname and certificate mismatch

Check the complete hostname in the address bar, including every subdomain. Open the browser’s certificate details and inspect the Common Name and Subject Alternative Names (SANs). The requested hostname must appear in the SAN list or match an applicable wildcard pattern.

For a command-line check, set the variable to the hostname you are testing:

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

The -servername option sends the hostname through SNI, which is important on shared HTTPS infrastructure. Run diagnostic commands before making configuration changes.

2. Add the hostname to the certificate

If the certificate covers the bare domain but not the failing subdomain, reissue or replace it with one that includes the required hostname as a SAN. A wildcard certificate may cover multiple one-level subdomains, but confirm coverage for the bare domain and any deeper subdomains separately.

If using Certbot, first confirm that you are authorized to request and deploy a certificate for the domain, that the webroot is correct, and that the validation method is suitable for the server. Include every required name in the issuance request:

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

This obtains a certificate but does not by itself install or activate it. Use the issuance method and webroot appropriate for the server, then install the certificate on the endpoint that terminates HTTPS and assign it to the correct hostname.

3. Check shared hosting and origin-server configuration

In the hosting control panel, confirm that a certificate is installed and assigned to the exact domain or subdomain. On a shared server, ask the provider to verify SNI-based certificate selection and the HTTPS virtual-host configuration.

Reload or restart the web server only after confirming the certificate files, permissions, and configuration are correct. A reload or restart can interrupt service, so follow the provider’s change procedure and obtain the required authorization before applying it.

4. Check CDN and load-balancer certificate coverage

Verify that the exact hostname is configured on the CDN or load balancer and included in its edge certificate. Confirm that the hostname routes to the intended origin as well.

If the CDN terminates HTTPS, the origin certificate alone does not resolve a browser mismatch. The certificate served by the public edge endpoint must cover the hostname. If the CDN passes HTTPS through, inspect the certificate at the origin instead.

5. Verify DNS for IPv4 and IPv6

Compare the hostname’s A, AAAA, and CNAME records with the endpoint or target supplied by the hosting or CDN provider. Check whether the failing network uses IPv4 or IPv6 and whether both paths reach the intended service.

Correct stale or unintended records only after confirming the intended endpoint and the appropriate DNS change procedure. Check the result from the affected network because cached DNS responses may persist until their TTL expires.

6. Re-test the same HTTPS hostname

After changing certificate assignment, routing, or DNS, test the exact URL that failed. Inspect the returned certificate again and confirm its SAN list, issuer, and validity dates. Test from the affected network as well as from the hosting, CDN, or server environment to distinguish propagation or resolver differences from an active misconfiguration.

Prevention & how to verify the fix

• Include certificate coverage whenever you add a subdomain, change DNS, migrate hosting, or add a CDN.
• Use SAN coverage or an appropriately scoped wildcard only after checking the bare domain, one-level subdomains, and deeper names the service actually uses.
• Keep DNS records, CDN hostnames, load-balancer listeners, origin virtual hosts, and certificate assignments aligned.
• Test both A and AAAA paths after DNS changes.
• Inspect the certificate served by the public endpoint instead of relying only on the absence of a browser warning.
• Record which service terminates HTTPS so certificate changes are made at the correct layer.
• Maintain certificate renewal and deployment procedures that include every required hostname.

Frequently asked questions