Short answer

A hostname mismatch means the domain you are connecting to is not listed in the certificate's Subject Alternative Name (SAN) list. Modern clients ignore the old Common Name (CN) field entirely and validate only against SAN. If the certificate is issued to www.example.com but the user goes to example.com (or vice versa), validation fails — even though the certificate is otherwise perfectly valid.

Confirm which names the certificate covers

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

The output shows e.g. DNS:www.example.com. If the domain you are visiting is not on the list, that is the cause of the error.

The common causes

  • www vs apex: The certificate covers www.example.com but not example.com. Fix: issue a certificate with both names in SAN, or redirect one to the other.
  • Wrong certificate on a multi-domain server: The client sent no SNI, so the server returned the default certificate for a different domain. See the SNI section of the handshake guide.
  • Wildcard limit: *.example.com covers one level — i.e. api.example.com, but not example.com itself, and not a.b.example.com either.
  • IP address instead of a name: You connect to https://203.0.113.10 while the certificate only carries DNS names.

SAN vs CN: why the old field is dead

Historically the domain was placed in the certificate's Common Name. Since 2017 browsers ignore CN and require all valid names to be in the SAN field. A certificate without SAN — whatever the CN says — will therefore fail in modern clients. This is also why self-signed certificates generated with old one-liners often fail: they lack a SAN.

How to fix it

  1. Add the missing name to SAN by issuing a new certificate. With ACME you simply add the domain to the certificate's name list.
  2. Or use a wildcard if you have many subdomains — but be aware of wildcard risks.
  3. Or redirect apex to www (or vice versa) at the server level, so users never hit the name the certificate does not cover.

If you generate a self-signed certificate for testing, remember to set SAN explicitly:

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem \
  -days 365 -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:dev.local,IP:127.0.0.1"

Avoiding mismatches in production

Hostname mismatches often appear when a new subdomain goes live but is not added to the certificate. CertControl scans your domains, discovers new subdomains via Certificate Transparency and DNS, and flags endpoints where the certificate's SAN does not cover the name actually served — before your users see the warning.

Frequently asked questions

Does a www certificate also cover the domain without www?

No, not automatically. www.example.com and example.com are two different names. Both must be in SAN, otherwise one of them fails. Many therefore always issue both names together.

Does a wildcard *.example.com cover example.com itself?

No. A wildcard covers one level of subdomains, e.g. api.example.com, but not the apex domain example.com and not a.b.example.com either.

Why does the browser ignore Common Name?

Since 2017 browsers require valid names to be in the Subject Alternative Name field. CN is kept only for historical reasons and is no longer used for validation.

Can I get a certificate for an IP address?

It is possible with an IP in SAN, but most public CAs do not issue to private IPs. For internal IP addresses you typically use an internal CA.

See the platform Book a demo