Certificate Hostname Mismatch: Fix SAN and Name Errors

A certificate is issued for specific hostnames. When you connect to a name that is not on that list, a correct client refuses the connection even though the certificate is valid, unexpired and signed by a trusted authority. Every client words it differently:

x509: certificate is valid for www.example.com, not example.com            (Go)
Hostname mismatch, certificate is not valid for 'example.com'.             (OpenSSL 3.x)
hostname 'example.com' doesn't match 'www.example.com'                     (Python)
Hostname example.com not verified: certificate: ... DNS:www.example.com    (Java/OkHttp)
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'
NET::ERR_CERT_COMMON_NAME_INVALID                                          (Chrome)

For the browser version of this page, see ERR_CERT_COMMON_NAME_INVALID. This page covers the cause from the certificate side, which is the same everywhere.

How matching works

Modern clients match the hostname against the Subject Alternative Name (SAN) extension. The old Common Name (CN) field is ignored by browsers and by most libraries, so a certificate with the right CN and no matching SAN fails. Matching rules:

• Names are compared case-insensitively, exact.
• A wildcard such as *.example.com covers exactly one label: www.example.com and api.example.com match, but example.com and a.b.example.com do not.
• The apex (example.com) and www.example.com are different names. A certificate needs both listed.
• IP addresses match only against IP entries in the SAN, not DNS entries.

See the glossary entry on SAN certificates.

Step 1: see what the server presents

Request the certificate for the exact hostname, with SNI, and print its SAN list:

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

Typical output:

subject=CN = www.example.com
X509v3 Subject Alternative Name:
    DNS:www.example.com, DNS:example.com

Check whether the name in your error is in the list. To ask OpenSSL to run the comparison for you, add -verify_hostname example.com to s_client and look for Verify return code: 62 (hostname mismatch). The SSL Checker shows the same list without a terminal.

Step 2: decide which of the common causes you have

1. The certificate lacks the name. The most common version: issued for www only, but users visit the apex, or the reverse. Reissue with every name.
2. You are reaching the wrong server. The certificate is valid, but for a different site. This happens when DNS points at an old host, a shared host's default virtual host answers, or the client does not send SNI. Compare the subject in step 1 to your expected site.
3. A wildcard is being asked to do too much. *.example.com will not cover example.com or two-level names like dev.api.example.com.
4. You connect by IP. https://203.0.113.10/ fails unless the certificate has an IP SAN. Use the hostname, or curl --resolve to test with the right name.
5. A CDN or proxy presents a default certificate because the hostname was not added to it, or the certificate is still pending issuance. See Cloudflare error 526 और Shopify SSL certificate pending.
6. A load balancer or ingress with several certificates serves a default one because its SNI rule does not match your hostname.

Step 3: confirm DNS points where you think

If the subject belongs to a different company or product, DNS is the problem, not the certificate. Check the A and CNAME records with the DNS चेकर, and identify who answers with the Website Hosting Checker or CDN डिटेक्टर. A dangling or reassigned target can serve someone else's certificate, which also has security implications; see subdomain takeover and dangling DNS.

Fix it

Reissue the certificate with all required names. With certbot, list every hostname and expand the existing certificate:

sudo certbot certonly --nginx --expand -d example.com -d www.example.com

For names that need wildcards, certificate authorities such as Let's Encrypt require DNS validation. Then reload the web server so it loads the new files, and make sure each server_name in nginx or ServerName / ServerAlias in Apache references a certificate that includes it.

Serve the right certificate for each name. On shared IPs, every server block needs its own ssl_certificate, and SNI must be enabled in the client and server. Very old clients without SNI support always get the default site.

Redirect carefully. If you want users on the apex to land on www, the apex still needs a valid certificate to answer the redirect. A redirect cannot happen before the TLS handshake, so an apex without a matching certificate shows the error instead of redirecting.

Verify

Re-run step 1, check that DNS: entries include the hostname, then test each variant: apex, www, and any subdomain. The Bulk SSL Checker can test a whole list of hostnames at once. Also confirm the chain is complete; see incomplete certificate chain.

अगले कदम

• Check names and expiry with the SSL Checker.
• View the full chain with the SSL Chain Debugger.
• Learn how certificates differ in SSL certificate types.
• Read the openssl s_client verify codes.

सामान्य प्रश्न

Does a wildcard certificate cover the bare domain?

No. *.example.com does not match example.com. Most certificates list both names in the SAN.

Does the Common Name still matter?

Not for hostname matching in current browsers and most libraries. Put every name in the SAN list.

Why does it work on www but not the apex?

The certificate was probably issued for www.example.com only. Reissue it with both names.

Can I connect to an IP address over HTTPS?

Only if the certificate includes that IP as an IP SAN. Public certificate authorities rarely issue these, so use a hostname.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.