NET::ERR_CERT_COMMON_NAME_INVALID
The site’s security certificate was issued for a different domain name, so the browser can’t confirm it’s really your site.
Also appears as
- Warning: Potential Security Risk Ahead Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for my-app.com. The certificate is only valid for *.netlify.app. Error code: SSL_ERROR_BAD_CERT_DOMAIN
Prompt to fix it
Visitors to my custom domain see "Your connection is not private" with NET::ERR_CERT_COMMON_NAME_INVALID. Check which certificate the domain actually serves (with curl -vI or openssl s_client) and which names it covers. Compare that with the domains configured for this project on our host and with the DNS records. Tell me exactly what to add or change: the domain in the host’s settings, records for www and the bare domain, CAA records, or Cloudflare proxy settings. Don’t suggest clicking through the warning or turning off HTTPS.
Paste into Layerwise or any AI coding tool.
What it means
Every HTTPS site shows the browser a certificate that lists the domain names it covers. This error means the certificate the server sent doesn’t include the name in the address bar. The certificate is often perfectly valid for another name, such as *.vercel.app or the bare domain without www.
It shows up most often right after you point a custom domain at a host. DNS already sends visitors to the host, but the host doesn’t know the domain belongs to your project, so it answers with its own default certificate. Adding the domain in the host’s settings lets it issue a certificate for your name, usually within minutes.
Behind Cloudflare’s proxy, the free certificate covers the bare domain and one level of subdomains, like app.my-app.com. A deeper name like api.staging.my-app.com gets this error even when everything else is set up right.
Common causes
- DNS points the domain at the host, but the domain was never added to the project in the host’s settings.
- The certificate covers
my-app.comand the visitor typedwww.my-app.com, or the other way around. - The host is still issuing the certificate, or a CAA record (a DNS rule naming which certificate authorities may issue for the domain) blocks it.
- The domain runs through Cloudflare’s proxy and uses a subdomain two levels deep.
- DNS still points to an old server or a previous host that has no certificate for the name.
How to fix it
- Click Not secure in the address bar, open the certificate details, and note which names it lists.
- If it lists the host’s own domain, such as
*.vercel.appor*.netlify.app, add your domain in the host’s domain settings and wait until its certificate shows as valid. - Add both the bare domain and
wwwto the project, and redirect one to the other. - If the domain has CAA records, make sure they allow your host’s certificate authority, for example
0 issue "letsencrypt.org". - Behind Cloudflare, keep proxied names one subdomain deep, or set that record to DNS only so the host serves its own certificate.
- Once the host shows the certificate as issued, reload the site in a private window and confirm the padlock is back.
Related errors
All errorsERR_TOO_MANY_REDIRECTS
The site keeps redirecting the browser in a circle, usually between HTTP and HTTPS or between two domains, so the browser stops trying.
DNS_PROBE_FINISHED_NXDOMAIN
The browser asked DNS where your domain lives and was told the name doesn’t exist, usually because a record is missing or still spreading.
Mixed Content: requested an insecure resource
Your secure https page tried to load data or code over plain http, and the browser blocked that request to keep the page secure.
Error 522: Connection timed out
Cloudflare couldn’t open a connection to the server behind your site in time, so it showed its own error page in place of your app.
Build with an agent that checks its work
The Layerwise agent clicks through the live preview and reads the console, so it catches errors before you do.