← Blog

NET::ERR_CERT_COMMON_NAME_INVALID: find the name your certificate is missing

2026-09-15

Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID when the hostname in the address bar isn’t one of the names on the certificate the server sent. The certificate may be valid, trusted, and months from expiry; it just belongs to a different name. Fixing it means finding out which names the certificate does cover, and why the server sent that certificate for this address.

If you’re a visitor rather than the site owner, there’s usually nothing on your side to fix. The exception is a public Wi-Fi login page or a corporate proxy intercepting the connection, covered below. Don’t click through the warning on a site where you’d enter a password.

The error name is misleading

Browsers stopped matching against the certificate’s Common Name years ago. Chrome removed Common Name matching in Chrome 58 in 2017, and publicly trusted CAs have been required to include the Subject Alternative Name (SAN) extension since the first Baseline Requirements took effect in July 2012, which already marked the Common Name as deprecated. Only the SAN list counts. The error kept its old name.

So guides that tell you to check the Common Name can send you the wrong way. A certificate with CN=example.com and a SAN list that doesn’t include example.com still fails for example.com.

See the names on the certificate

Run this from any machine with OpenSSL 1.1.1 or later, replacing both hostnames with the one that shows the error:

openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Output for that test host:

subject=CN=*.badssl.com
X509v3 Subject Alternative Name:
    DNS:*.badssl.com, DNS:badssl.com

The openssl that ships with macOS is LibreSSL, which rejects -ext with unknown option -ext. There, replace -subject -ext subjectAltName with -text and look for the X509v3 Subject Alternative Name line, or install OpenSSL from Homebrew.

wrong.host.badssl.com is two labels below badssl.com, and a wildcard only covers one, so this certificate doesn’t match. OpenSSL can say so directly: run the s_client half on its own, without the pipe into x509, and add -verify_hostname wrong.host.badssl.com. Near the end of its output you get Verify return code: 62 (hostname mismatch).

Keep -servername anyway. OpenSSL 1.1.1 and later send the -connect hostname as the server name on their own, but when you connect to an IP address, as in the multi-server check further down, no name goes out unless you pass one. Without it, a shared server or CDN answers with its default certificate, and you end up diagnosing a certificate the browser never received.

Match the SAN list to the cause

Compare the hostname you visited with the DNS: entries in that output. Each of these five patterns points to a different cause.

1. www.example.com is listed but example.com isn’t (or the reverse)

The certificate was issued for one form of the name only. Reissue it with both. Most CAs and ACME clients accept several names in one request.

2. *.example.com is listed, and you visited example.com or a.b.example.com

A wildcard covers exactly one label: not the bare domain, and not two levels down. Add example.com explicitly, or *.b.example.com for the deeper level.

3. The names belong to your host or CDN

Entries like *.herokuapp.com, *.azurewebsites.net, or a shared-hosting server name mean DNS points at the platform, but the platform has no certificate for your custom domain yet, or doesn’t recognize the name at all. Finish the custom-domain setup on the platform, check that the DNS record matches what it asked for, and wait for its certificate to be issued.

4. The names belong to an old server or another site

DNS still points at a server you migrated away from, or a stale record (an AAAA record, or a second A record) sends some visitors there. Fix or remove the outdated record.

5. Only DNS: names, and you’re connecting to an IP address

An IP address only matches an IP Address: SAN entry, never a DNS name. Connect by hostname, or use a certificate that lists the address as an IP Address: entry. Let’s Encrypt issues these as six-day certificates, and an internal CA can issue them for private networks.

Case 4 is the one that wastes the most time. If the site works for you and fails for a colleague, run the command against each resolved address: dig +short example.com A and dig +short example.com AAAA list them, and openssl s_client -connect 203.0.113.10:443 -servername example.com checks one.

When the problem is on the visitor’s network

If the certificate the command returns looks correct but one person still sees the error, something between that person and the site is answering instead. Two things commonly do this:

  • A captive portal on hotel, airport, or café Wi-Fi intercepts the first HTTPS request and answers with its own login page’s certificate. Open any plain http:// page to trigger the login, then retry
  • A corporate proxy or security product that inspects HTTPS answers with its own certificate. These usually cause ERR_CERT_AUTHORITY_INVALID instead, but a misconfigured one can present a certificate for the wrong name. The fix belongs to whoever runs the proxy

Advice to fix the computer’s clock, clear the browser’s SSL cache, or disable extensions is aimed at other certificate errors. A wrong clock produces ERR_CERT_DATE_INVALID, not a name mismatch.

Renewals can drop names

A certificate that worked for a year can start failing the day it renews. Common ways a name disappears: the renewal ran from a config file that listed fewer domains than the original order, someone reissued a single-name certificate to replace a multi-name one, or a platform moved the site to a new certificate that only covers the primary domain. Run the command above after every renewal, for each name you serve, not just the main one.

Renewals are becoming more frequent: maximum certificate lifetime is dropping to 100 days in March 2027 and 47 days in 2029, so there will be more chances for this to happen.

Where Certly fits

The free checker reads public Certificate Transparency logs and shows the issuer and expiry of the most recent certificate issued for your hostname. It doesn’t connect to your server, so it can’t show which certificate the server is sending or which names it lists; that’s what the openssl command above is for. Certly monitoring does connect: it checks the certificate your server actually serves on a schedule. The free plan covers two sites with email alerts; paid plans add Slack, Discord, and webhook alerts.

Sources