Skip to main content
All fixes

SSL, TLS, security headers

Fix SSL certificate hostname mismatch errors in browsers

The certificate's Subject Alternative Name list does not include the requested hostname, so browsers throw NET::ERR_CERT_COMMON_NAME_INVALID. Reissue with the correct SAN.

What's happening

A hostname mismatch means the certificate served on the connection does not list the requested hostname in its Subject Alternative Name (SAN) extension. Modern browsers ignore the legacy Common Name field entirely and only look at SAN; a certificate for example.com will not validate for www.example.com unless www.example.com is explicitly in SAN.

Chrome reports NET::ERR_CERT_COMMON_NAME_INVALID with 'This server could not prove that it is example.com'. Firefox reports SSL_ERROR_BAD_CERT_DOMAIN. Safari blocks the connection. The TLS handshake itself completes and the client fetches the certificate, but the verify step fails because the SNI hostname does not match any SAN entry.

The fix is to reissue the certificate with the correct SAN list, or to point the request at a hostname that is already covered. Either way the certificate has to actually contain the name the user typed in the address bar.

Why it matters

Visitors typing the affected hostname see a hard browser warning and bounce. The damage is concentrated on whichever variant is misconfigured — typically the apex versus www mismatch — and you may not notice it from your own bookmark.

Webhook senders and API consumers connecting to the missing variant fail their TLS verification. If you advertise both apex and www in documentation, half your integrations break.

SEO ranking signals split between the two hostnames are wasted because one of them is unreachable. Search Console flags the affected URL with an HTTPS error.

Common causes

  • Certificate was issued for example.com only, but DNS routes both example.com and www.example.com to the same listener.
  • Certificate was issued for *.example.com, which covers www but not the apex; wildcards do not match the parent label.
  • A multi-domain SAN cert was reissued and someone forgot to add a recently launched subdomain.
  • Cloud load balancer is using a default certificate for unmatched SNI requests instead of returning the right cert per hostname.
  • DNS A or CNAME records point a hostname to a different origin than the one whose certificate covers it.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open SSL Checker

How to fix it

  1. 1

    List every SAN in the served certificate

    Run openssl s_client -servername www.example.com -connect www.example.com:443 /dev/null | openssl x509 -noout -ext subjectAltName. Compare the listed DNS names against the hostname the user typed. Repeat for each variant — apex, www, and any subdomain you serve.

  2. 2

    Decide on the SAN coverage you actually need

    Most public sites need both example.com and www.example.com. SaaS platforms with customer subdomains often need a wildcard plus the apex. Audit your DNS zone for hostnames that resolve to your edge but are not in the certificate.

  3. 3

    Reissue with certbot

    Run sudo certbot certonly --nginx -d example.com -d www.example.com -d api.example.com. Certbot will request a new certificate covering all listed names. For a wildcard, use the DNS-01 challenge: sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com.

  4. 4

    Reissue from your cloud provider

    In AWS ACM, request a new public certificate with multiple Domain Names. In Cloudflare, the Universal certificate covers both apex and one level of subdomain by default; for deeper subdomains use Advanced Certificate Manager. Update the listener or distribution to use the new ARN or certificate ID.

  5. 5

    Reload the web server

    Run sudo nginx -t && sudo systemctl reload nginx. Confirm the new certificate is served by re-running step 1 with -servername set to each hostname you care about. Each request should return the same certificate with the correct SAN list.

  6. 6

    Verify in browsers and curl

    Open every hostname in a clean browser window. Run curl -v https://example.com and curl -v https://www.example.com. No flags, no errors expected. The SSL Checker at /ssl will also flag remaining hostname-mismatch issues.

Example

# Inspect SANs on the wire
openssl s_client -servername www.example.com -connect www.example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

# Reissue covering both apex and www
sudo certbot certonly --nginx \
  -d example.com \
  -d www.example.com

Inspect SAN coverage and reissue with the missing hostnames

Frequently asked

No. A wildcard matches exactly one DNS label to the left of the wildcard so *.example.com matches www.example.com and api.example.com but not example.com itself. You need a SAN that lists example.com explicitly alongside the wildcard.

Yes via Server Name Indication (SNI). The TLS client sends the requested hostname during the ClientHello and the server returns the matching certificate. Every modern client supports SNI; only ancient embedded clients and Windows XP do not.

Related fixes

SSL, TLS, security headers

Replace self-signed SSL certificate with a trusted CA cert

SSL, TLS, security headers

Fix incomplete SSL certificate chain and intermediate errors

SSL, TLS, security headers

Limit wildcard SSL certificate scope to reduce blast radius

SSL, TLS, security headers

Force HTTP-to-HTTPS redirects on every hostname you serve