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 Invalid 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 and shows visitors a warning. It's a deliberate security guarantee that stops one site's certificate from being used to impersonate another, the same protection that, this time, is getting in your way.

Browser warnings you might see

The full-page warning is generic: "Your connection is not private" (Chrome and Edge), "Warning: Potential Security Risk Ahead" (Firefox), or "This Connection Is Not Private" (Safari) shows for any certificate problem. It's the error code underneath that points specifically at a hostname mismatch:

Where	What it says
Chrome / Edge	NET::ERR_CERT_COMMON_NAME_INVALID
Firefox	SSL_ERROR_BAD_CERT_DOMAIN
Safari	"…because its identity cannot be verified"
curl	curl: (60) SSL: no alternative certificate subject name matches target host name

If you see one of these, the certificate being served doesn't list the domain you're visiting. If the code instead mentions DATE_INVALID, it's a validity problem rather than a hostname one. See certificate expired or certificate not yet valid.

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.

Worked examples

The SAN list doesn't include your domain

You've added shop.example.com, but the certificate only covers the apex and www. The SAN check shows it plainly:

$ openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com

shop.example.com isn't in the list, so the browser refuses it. Expand the certificate to include the new name and reload:

$ sudo certbot --expand -d example.com -d www.example.com -d shop.example.com
$ sudo systemctl reload nginx

A wildcard that doesn't cover the apex

A classic trap: the subdomains work but the bare domain fails:

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

*.example.com matches www.example.com and shop.example.com, but not example.com itself. The certificate needs the apex listed alongside the wildcard (wildcard issuance uses DNS validation):

$ sudo certbot certonly --preferred-challenges dns \
    -d "*.example.com" -d example.com

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 and find the Security card (it's the SSL certificate panel on the site's page), then wait for the next automatic check. DomainDash re-checks the certificate on its normal schedule, and the card will update once it sees the new certificate. The status should flip from Invalid to Valid, 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