How to fix NET::ERR_CERT_COMMON_NAME_INVALID on your website

NET::ERR_CERT_COMMON_NAME_INVALID means the browser could not match the hostname in the address bar to the certificate it received. Fix it by identifying the certificate your TLS endpoint serves, comparing its Subject Alternative Name (SAN) entries with that hostname, and installing a matching certificate on the endpoint that handles the connection.

This guide assumes you operate the website. Start with the exact URL a customer reports, including whether it begins with www or a different subdomain. A healthy certificate for example.com tells you little about app.example.com.

1. Read the certificate the public host serves

Open the SSL certificate checker and enter the hostname from the failing URL. Read the covered names and issuer. The checker can inspect a certificate even when it is expired or untrusted, so treat its dates and name result as separate facts.

With OpenSSL 3, you can inspect the leaf certificate from a terminal:

openssl s_client -connect app.example.com:443 \
  -servername app.example.com </dev/null |
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Replace both hostnames with the one you are investigating. The -servername option sends Server Name Indication (SNI). A server hosting several sites can select a different certificate when SNI is missing. OpenSSL documents this behavior in s_client.

The final command prints the first certificate from the connection. It reads fields; it does not perform a complete trust or hostname verification.

If you already have the proposed replacement certificate, paste it into the certificate decoder. Enter the intended hostname in the comparison field. Compare the file with the live result before changing anything.

2. Compare SAN with the exact hostname

Despite the error's name, the field you need is usually SAN, not the certificate's Common Name. Chrome removed Common Name fallback in version 58. A certificate whose subject says CN=app.example.com can still fail if its SAN does not contain the required name.

For this example:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

The expected matches are:

RFC 9525 describes service identity matching, including the whole-label wildcard rule. Do not assume a wildcard includes the bare domain. If both example.com and www.example.com serve HTTPS, arrange coverage for both.

3. Find the endpoint that chooses the certificate

The certificate installed on your application server might differ from the one customers receive. Work from the client inward.

For Nginx, check that the intended server_name and certificate belong to the same HTTPS server block. Its HTTPS configuration guide explains how a default server's certificate can be selected and how SNI affects selection.

If DNS recently changed, compare the hostname's answers with the DNS lookup tool. An old address may lead some clients to a previous load balancer. Investigate differing answers before declaring them wrong: CDN routing can legitimately return different addresses, as the DNS differences guide explains.

When testing one known backend directly, keep the public hostname as SNI:

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

The address above is a documentation example. Replace it with an endpoint you administer. This checks that backend's selected certificate; it does not recreate the entire CDN path.

4. Fix the missing name or the wrong binding

If the intended hostname is absent from SAN, request a certificate that includes it, complete the issuer's validation process, and install it at the TLS termination point. Editing the Common Name on a local file cannot add a signed SAN entry.

If SAN already contains the hostname but the live checker sees a different certificate, fix the listener, virtual-host or edge binding. Reload or deploy through that platform's normal process, then check the public endpoint again. Reissuing a correct file repeatedly will not fix a listener serving another file.

An HTTPS redirect needs a matching certificate on its source hostname too. The TLS handshake happens before the browser receives the redirect, so a redirect from https://old.example.com cannot repair that hostname's certificate failure.

5. Verify the deployed path and keep watching it

Recheck every affected hostname, including the apex, www, API and customer subdomains involved in the report. Use a fresh connection after deployment. If only certain users still fail, compare their resolved addresses and network path rather than assuming a browser cache is responsible.

A name match answers one question. The client must also validate dates and the certificate chain. If Node.js reports a signature-chain error instead, follow unable to verify the first certificate.

Keep an HTTPS monitor with TLS verification enabled beside a certificate expiry monitor. The former catches validation failures; the latter warns about approaching expiry. Follow the certificate monitoring walkthrough to configure both checks and test where their alerts land.

Frequently asked questions

What does NET::ERR_CERT_COMMON_NAME_INVALID mean?

The browser could not match the hostname in the URL to the certificate the server presented. Inspect the certificate's Subject Alternative Name extension and the TLS endpoint serving it. A certificate can have current dates and a trusted issuer while covering the wrong hostname.

Does a wildcard certificate cover the root domain?

A certificate for *.example.com covers one label such as api.example.com. It does not cover example.com or a.b.example.com. Include the root domain as a separate DNS name if you need it.

Can an HTTPS redirect fix a certificate name mismatch?

No. The client verifies the TLS certificate before it receives an HTTP redirect. The source HTTPS hostname needs a matching certificate even if it only redirects visitors elsewhere.