# NET::ERR_CERT_COMMON_NAME_INVALID

"NET::ERR_CERT_COMMON_NAME_INVALID" means Chrome could not match the hostname in the address bar to any name in the certificate's Subject Alternative Name extension. Despite the name of the error, Chrome has ignored the Common Name field since Chrome 58, so a certificate whose CN is exactly right still fails this check if it carries no SAN extension listing that hostname. Nothing about trust, expiry or the certificate chain is wrong when this error appears — the certificate is valid, it was simply issued for different names. Run `openssl x509 -in certificate.crt -noout -ext subjectAltName` to list the names it does cover, and reissue the certificate with the missing hostname among them.

Source: https://certguru.io/errors/err-cert-common-name-invalid/
Last updated: 2026-08-19
Commands verified against OpenSSL 3.5.7.

---

> **The exact message**
>
> ```
>   Your connection is not private
>   NET::ERR_CERT_COMMON_NAME_INVALID
>   ```
>   Chrome expands it as *"This server could not prove that it is example.com; its security
>   certificate is from other.example.com."*

## What the error actually means

Certificate validation asks two independent questions: *is this certificate trustworthy*, and *does
it belong to the host I asked for*. This error is a failure of the second question only. The
signature is fine, the chain is fine, the dates are fine — the certificate simply does not carry the
name you typed.

> **The Common Name is not consulted at all**
>
> The error name is misleading. Since Chrome 58, released in 2017, Chromium matches hostnames
>   **only** against the Subject Alternative Name extension. A certificate whose Common Name is
>   exactly `example.com` and which has no SAN extension produces this error on `example.com`. If you
>   have been staring at a correct-looking CN wondering what Chrome is complaining about, this is why.

## Step 1 — list the names the certificate covers

*Read the SAN extension*

```bash
openssl x509 -in certificate.crt -noout -ext subjectAltName
```

Expected output:

```
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
```

The hostname in the address bar must appear in that list literally, or be covered by a wildcard.
If the command prints nothing at all, the certificate has no SAN extension and will fail against
every modern browser regardless of its Common Name:

*Subject and SAN side by side*

```bash
openssl x509 -in certificate.crt -noout -subject -ext subjectAltName
```

For a certificate you have not been given as a file, read it off the live server:

*Read the SAN list from a running server*

```bash
openssl s_client -connect example.com:443 -servername example.com /dev/null \
  | openssl x509 -noout -subject -ext subjectAltName
```

## Step 2 — find which case you are in

| Symptom | Cause | Fix |
| --- | --- | --- |
| SAN list is empty | Certificate predates SAN, or the CSR omitted it | [Reissue with SANs](#step-3--reissue-with-every-name-the-service-answers-on) |
| SAN has `example.com`, you browsed `www.example.com` | Both names were not requested | Reissue with both |
| SAN has `*.example.com`, you browsed `example.com` | A wildcard does not cover the bare domain | Reissue adding `example.com` |
| SAN has `*.example.com`, you browsed `a.b.example.com` | A wildcard covers one label only | Reissue adding `*.b.example.com` |
| You browsed an IP address | SAN carries DNS names, not `IP:` entries | Use the hostname |
| Subject is a hosting provider's name | The server is serving its default certificate | [SNI or vhost problem](#when-the-server-serves-the-wrong-certificate) |

## Step 3 — reissue with every name the service answers on

Names are covered by the CA's signature, so they cannot be added afterwards. Generate a new CSR
listing all of them:

*A CSR carrying the apex and www*

```bash
openssl req -new -newkey rsa:2048 -nodes \
  -keyout site.key -out site.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"
```

Confirm the extension survived into the CSR before sending it to the CA — this is the step that
most often goes wrong silently:

```bash
openssl req -in site.csr -noout -text | grep -A1 "Subject Alternative Name"
```

The full walkthrough, including the config-file form for long name lists, is on
[generate a CSR with SANs](/openssl/generate-csr-with-san/).

> **Put the primary name in the SAN list too**
>
> A name in the Common Name but missing from the SAN list is invisible to browsers. Every hostname
>   must appear in the SAN extension, including the one you also put in the CN.

## When the server serves the wrong certificate

If the certificate you are looking at belongs to someone else entirely — a hosting provider, a CDN,
or another site on the same box — the certificate is not the problem. The server picked the wrong
virtual host.

*Compare what the server returns with and without SNI*

```bash
openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -subject
openssl s_client -connect example.com:443 /dev/null | openssl x509 -noout -subject
```

Two different subjects means the server has a default certificate that is answering for
unrecognised names. Either the `server_name` directive does not list the hostname, or the request is
reaching a different backend than you expect. The nginx side of this is covered in
[install an SSL certificate on nginx](/platforms/nginx/).

## What not to do

> **Clicking through the interstitial trains the wrong habit**
>
> Chrome's *Advanced → Proceed* link, and typing `thisisunsafe` on the warning page, both suppress
>   the check for a certificate that genuinely does not identify the host you are talking to. For a
>   development box this is merely a bad habit; on anything reachable from the internet the warning is
>   describing a real gap between the name you asked for and the name that answered.


## Frequently asked questions

### The Common Name is correct, so why does Chrome say it is invalid?

Chrome stopped reading the Common Name in Chrome 58, following RFC 2818's deprecation of the practice. Name matching now uses the Subject Alternative Name extension exclusively. A certificate with a perfect CN and no SAN extension fails against every current browser, and the error name is simply a historical artefact.

### Does a wildcard certificate cover sub-subdomains?

No. `*.example.com` matches `api.example.com` but not `a.b.example.com`, and it does not match the bare `example.com` either. A wildcard replaces exactly one label, which is why certificates usually list both `*.example.com` and `example.com`.

### Can I add a hostname to a certificate that has already been issued?

No. The names are covered by the CA's signature, so changing them invalidates it. Generate a new CSR listing every name and have the certificate reissued — most CAs do this at no extra cost within the existing term.

### Why does this only happen when I browse by IP address?

The SAN list must contain `IP:10.0.0.5` for an IP address to match, and public CAs will not issue those. Use the hostname instead, and override DNS locally if that is the obstacle.

### Chrome shows this but curl does not complain. Why?

Check which certificate each is receiving. If curl omits SNI or connects to a different address, the server may answer with a different virtual host. Compare `openssl s_client -servername` output against what the browser reports in the certificate viewer.


## References

- [RFC 6125: representation and verification of service identity](https://www.rfc-editor.org/rfc/rfc6125) — the matching rules browsers implement, including wildcard scope
- [RFC 2818 section 3.1: HTTP over TLS server identity](https://www.rfc-editor.org/rfc/rfc2818#section-3.1) — the clause deprecating Common Name that Chrome 58 acted on
- [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/) — what a publicly trusted CA is permitted to put in a SAN list

## Related pages

- https://certguru.io/errors/err-cert-authority-invalid/
- https://certguru.io/concepts/san/
- https://certguru.io/openssl/generate-csr-with-san/
- https://certguru.io/concepts/wildcard-certificate/
- https://certguru.io/errors/curl-60-ssl-certificate-problem/
- https://certguru.io/openssl/view-certificate/
- https://certguru.io/platforms/nginx/
- https://certguru.io/concepts/self-signed-vs-ca-signed/

--
CertGuru — https://certguru.io