Hostname doesn't match certificate

The SSL certificate served by your site was issued for a different domain than the one we're checking. Browsers reject this because it could be a sign of a misconfigured server or a man-in-the-middle attempt.

Symptom

• DomainDash marks the SSL check as Down with error code wrong_host
• Visitors see a browser warning like "This certificate is not valid for the requested domain" or NET::ERR_CERT_COMMON_NAME_INVALID
• Running openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text shows a Subject and SAN that don't include your domain

What it means

Every SSL certificate lists the domain (or domains) it's valid for in two places: the Subject Common Name (CN) and the Subject Alternative Name (SAN) extension. Modern browsers only check the SAN. If the domain being requested isn't in the SAN list, the browser rejects the connection. This is a deliberate security guarantee that stops one site's certificate from being used to impersonate another.

Common causes

• You added a new subdomain (e.g. shop.example.com) but your certificate only covers the apex (example.com).
• You're serving the same certificate for www.example.com and example.com but the certificate only includes one of them.
• You switched from a single-domain certificate to a wildcard but the wildcard doesn't cover the requested host (e.g. *.example.com doesn't cover example.com itself).
• The wrong virtual host is responding. Your server has multiple sites configured but the default/fallback host is serving its own certificate to requests for your domain.
• Your CDN or reverse proxy is using a default certificate because your custom certificate hasn't been uploaded or attached to the right hostname.
• DNS points the wrong way — the domain resolves to a server that legitimately serves a different site's certificate.

How to fix

1. List the domains your certificate actually covers. Run:

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

   You'll see a line like DNS:other.com, DNS:www.other.com. If your domain isn't in this list, the certificate doesn't cover it.

2. Decide whether to issue a new certificate or fix DNS. If the certificate is legitimately the wrong one for this host, you need a new certificate that includes your domain. If DNS is pointing at the wrong server, fix DNS instead.

3. For Let's Encrypt with certbot, add the missing domain to the certificate:

   sudo certbot --expand -d example.com -d www.example.com -d shop.example.com

   Then reload your web server.

4. For hosted providers (Cloudflare, Netlify, Vercel, etc.), add the domain in the dashboard. Most providers will issue a new certificate covering all configured custom domains within a few minutes.

5. For wildcard certificates, confirm whether you need the apex too. *.example.com does not cover example.com. You need both certificates or a multi-SAN cert.

6. If the wrong virtual host is responding, check your web server config (nginx -T, apachectl -S) and make sure the server_name / ServerName directives match the domains you're serving certificates for.

How to verify

1. Re-run the OpenSSL SAN check from step 1. Your domain should appear in the list.
2. Open the site in an incognito window. The padlock should appear with no warnings.
3. Open the site in DomainDash, go to SSL, and click "Check now". The status should flip from Down to Healthy — and the SAN list on the certificate card should now include your domain.

Related

• Self-signed certificate — sometimes a default fallback cert is self-signed
• Visitors see a security warning — if you're not sure what's wrong
• SSL certificates — how DomainDash checks SSL