Troubleshooting2026-08-15•4 min read

Hostname Mismatch: SSL Common Name and SAN Errors

· CSR.plus Team

•Browsers match the hostname against the certificate’s Subject Alternative Names (SANs), not the legacy Common Name field.
•A single-domain certificate covers exactly one hostname; a wildcard covers one level of subdomains; SAN certs cover a list.
•The fix is almost always a reissue with the correct SAN list — not a server configuration change.

CN_INVALID

Browser error

NET::ERR_CERT_COMMON_NAME_INVALID

SAN only

Matching source

CN ignored by modern browsers

1 level

Wildcard depth

*.example.com, not *.*

Reissue

Fix

with correct SAN list

How hostname matching works

When you visit www.example.com, the browser collects the certificate’s SAN entries and checks whether one matches. The Common Name field is ignored by modern browsers. A certificate for example.com does not cover www.example.com — they are different hostnames. This is the most common source of confusion behind hostname mismatch errors.

Wildcards and SAN certificates

A wildcard certificate *.example.com covers www.example.com and any other single-level subdomain, but not example.com itself and not deeper levels like a.b.example.com. A SAN (multi-domain) certificate can list several distinct hostnames. If you need both example.com and www.example.com, request a SAN certificate with both, or use a wildcard plus the bare domain.

The correct fix

Reissue the certificate with the exact hostnames you serve, including the www prefix if you redirect to it. Then deploy the new certificate and full chain. Check the served SANs with openssl x509 -in cert.pem -noout -text | grep -A1 "Subject Alternative Name". Do not "fix" this with server rewrites — the certificate must cover the hostname visitors actually connect to.