SSL Certificate Name Mismatch

An SSL certificate name mismatch means the certificate your server presents does not list the hostname the client asked for, so browsers block the page with a full-screen interstitial (NET::ERR_CERT_COMMON_NAME_INVALID in Chrome). Traffic is still encrypted; what breaks is the proof of who you are talking to. Rated medium: not directly exploitable, but it trains users to click through the warning a real attacker would trigger.

What is an SSL certificate name mismatch?

The client sends the hostname in the TLS SNI extension and matches the returned leaf certificate against its Subject Alternative Name (SAN) extension, per RFC 9525 (which obsoleted RFC 6125 in 2023). No SAN match, no trust — however valid the chain is.

The Common Name (CN=) is dead as an identity source: Chrome dropped commonName matching in version 58, Firefox in 48, and Safari never accepted CN-only certificates. Common causes:

• Apex vs www — the cert names example.com, visitors reach www.example.com, or the reverse.
• Wildcard depth — *.example.com matches api.example.com but not example.com itself, and not a.b.example.com.
• Default/fallback vhost — an unconfigured hostname resolves to your IP and the server hands back the first vhost's certificate.

It maps to OWASP Security Misconfiguration (A02:2025, formerly A05:2021); scanners tag CWE-297, which strictly describes the client accepting the bad certificate.

Why it's a risk / how it's exploited

The damage is behavioural, not a single-request exploit. If your site has thrown a name warning for six months, users are trained to tap Advanced → Proceed. An on-path attacker then presents a self-signed certificate, the victim dismisses a screen they have dismissed a hundred times, and the session cookie is gone. Behind HSTS there is no click-through at all — just an outage.

The bigger hit is machine clients. Cron jobs, webhooks and mobile SDKs hit the mismatch and someone "fixes" it with curl -k, verify=False, or rejectUnauthorized: false, permanently disabling all certificate validation for that client. That outcome is genuinely high severity and outlives the mismatch. A SAN belonging to a hosting provider rather than you is the fingerprint of a dangling DNS record — check it as a possible subdomain takeover.

How to detect it

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

You are vulnerable when the SAN omits the name you asked for, or lists something unrelated like DNS:*.cdnprovider.net.

-ext needs OpenSSL 1.1.1+; on older builds use -text | grep -A1 "Alternative Name". For a verdict rather than a listing, add -verify_hostname example.com (OpenSSL 1.0.2+): a good host prints Verification: OK, a mismatch prints Verification error: hostname mismatch and return code 62. curl on an OpenSSL build reports error 60, no alternative certificate subject name matches target host name. Rerun without -servername to expose a fallback vhost.

How to fix it

Reissue with every hostname on the cert (certbot --nginx -d example.com -d www.example.com -d api.example.com), then name hosts explicitly and reject unknown SNI:

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;    # nginx 1.19.4+; no cert needed here
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Apache 2.4 (mod_ssl) has no equivalent of ssl_reject_handshake, so order your vhosts to make the first a deliberate default:

<VirtualHost *:443>
    ServerName  example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

SSLStrictSNIVHostCheck on (Apache 2.2.12+) helps only at the margin: it refuses clients sending no SNI, with an HTTP 403 after the handshake completed with the default certificate. Unknown-but-present SNI names still land on that vhost. Managed platforms have their own limits: Cloudflare's Universal SSL stops at first-level subdomains, and ACM certs on CloudFront or an ALB must name every alternate domain.

Redirecting www → apex does not remove the need for www in the SAN: the handshake completes before your 301 is sent. And a correct name says nothing about dates or negotiation — check expired certificates and weak cipher suites too.

FAQ

Is an SSL certificate name mismatch exploitable on its own? Not directly. It needs an on-path attacker to substitute a certificate plus a user willing to click past the warning — which is why a chronic mismatch matters more than a one-off. Medium, not high: the crypto is fine, the identity guarantee is not.

Does a wildcard certificate cover all my subdomains? Only one label deep. *.example.com matches www.example.com and api.example.com, but not the apex example.com and not staging.api.example.com. Most CAs add the apex as a second SAN entry; deeper hosts need their own.

---

Name mismatches are cheap to check and rarely arrive alone, as any real vulnerability scan shows. Run a free website vulnerability scan: Exploita's AI agent checks the SAN of every hostname it finds, then keeps going into the application layer.