SSL/TLS Certificate Hostname Mismatch

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
CategoryCryptographic / Certificate Misconfiguration
Typical SeverityHigh
OWASPA07:2021 – Identification and Authentication Failures
CWECWE-297: Improper Validation of Certificate with Host Mismatch
Also known asCertificate CN Mismatch, SAN Mismatch, Wrong Certificate, Hostname Verification Failure
Affected systemsAny HTTPS web server, API endpoint, mail server (SMTP/IMAP/POP3 with TLS), LDAPS, or any TLS-secured service
Relevant RFCsRFC 9110 (HTTP Semantics), RFC 6125 (Hostname Verification), RFC 5280 (X.509 PKI)

Overview

An SSL/TLS certificate authenticates a server's identity by binding a public key to one or more domain names. Browsers and TLS clients verify that the hostname in the URL matches a name listed in the certificate's Subject Alternative Name (SAN) extension or, for legacy certificates, the Common Name (CN) field of the Subject. When no match exists, hostname verification fails.

RFC 6125 defines the authoritative rules for hostname verification in TLS. Since 2017, major browsers (Chrome, Firefox, Safari) and RFC 2818 require the SAN extension; the CN field is no longer sufficient on its own for modern clients. Sensagraph automatically detects hostname mismatches during TLS certificate inspection.

How it works

During the TLS handshake, the server presents its certificate chain. The client then performs hostname verification:

  1. The client extracts all dNSName entries from the SAN extension (and optionally iPAddress entries for IP-based access).
  2. Each entry is compared against the requested hostname using exact matching or wildcard matching (a single leading *. label, per RFC 6125 §6.4.3).
  3. If no SAN entry matches, the connection is rejected (or, in permissive/misconfigured clients, accepted with a warning).

Common scenarios that produce a mismatch:

  • Wrong certificate deployed: A certificate issued for example.com is served on api.example.com, which is not listed as a SAN.
  • Wildcard scope exceeded: A wildcard certificate for *.example.com covers api.example.com but not deep.api.example.com (wildcards match only one label).
  • IP address access: A certificate containing only a DNS SAN is accessed via its raw IP address, and no iPAddress SAN is present.
  • Certificate not updated after domain change: The server was migrated to a new domain but the certificate was not reissued.
  • Development/staging certificate in production: An internal or self-signed certificate intended for dev.internal is inadvertently served on a public-facing hostname.
  • Load balancer or CDN misconfiguration: Traffic is routed to a backend that presents a certificate for a different virtual host.

Business impact

A hostname mismatch directly breaks the server identity guarantee that TLS is designed to provide. The practical consequences include:

  • Man-in-the-middle (MitM) exposure: Users who click through browser warnings, or non-browser clients that disable hostname verification, are vulnerable to traffic interception and credential theft.
  • Service disruption: Strict clients (modern browsers, mobile apps, APIs using certificate pinning) will refuse to connect, causing outages or failed transactions.
  • Loss of user trust: Browser security warnings (NET::ERR_CERT_COMMON_NAME_INVALID in Chrome, SEC_ERROR_BAD_CERT_DOMAIN in Firefox) are highly visible and cause user abandonment.
  • Compliance violations: PCI DSS Requirement 4.2.1 and similar standards mandate valid, correctly scoped certificates for cardholder data environments. A mismatch can constitute a finding in QSA audits.
  • Automated pipeline failures: CI/CD systems, health-check agents, and API clients with strict TLS verification will fail, disrupting deployments and monitoring.

How to fix it

  1. Audit all hostnames in use. Enumerate every public and internal hostname that clients access over TLS. Verify that each is covered by the SAN of the certificate currently served on that endpoint.
  2. Reissue or replace the certificate. Obtain a new certificate from your CA with the correct SAN entries. For multiple subdomains, use a wildcard certificate (*.example.com) or a multi-SAN certificate that explicitly lists all required hostnames.
  3. Use automated certificate management. Deploy ACME-based automation (e.g., Let's Encrypt with Certbot or ACME clients built into web servers) to eliminate manual certificate lifecycle errors and ensure timely renewal.
  4. Never disable hostname verification in clients. Application code that sets flags such as CURLOPT_SSL_VERIFYHOST=0 (libcurl), verify=False (Python requests), or checkServerIdentity: () => undefined (Node.js) creates silent MitM vulnerabilities. Fix the certificate instead.
  5. Include IP SANs when necessary. If services must be accessed by IP address, include the IP as an iPAddress SAN in the certificate rather than relying on the CN.
  6. Monitor certificate inventory continuously. Use certificate transparency log monitoring and automated scanning to detect mismatches before they affect users.
  7. Apply HSTS after resolution. Once certificates are correct, deploy HTTP Strict Transport Security (HSTS) with an appropriate max-age to prevent protocol downgrade attacks.

References

Frequently asked questions

An expired certificate has passed its validity period (the notAfter date in the certificate), while a hostname mismatch means the certificate is valid but was issued for different domain names than the one being accessed. Both conditions cause TLS verification to fail, but they are distinct errors with different root causes and remediation steps.

A wildcard certificate (e.g., *.example.com) covers one level of subdomain depth. It matches api.example.com and www.example.com but does not cover deep.api.example.com or the apex domain example.com itself (unless the apex is also listed as a SAN). For complex subdomain structures, a multi-SAN certificate listing each hostname explicitly is more reliable.

Yes, but the certificate must contain an iPAddress SAN entry matching the IP address. A certificate that only lists DNS names will produce a hostname mismatch when accessed via IP. Most public CAs do not issue IP SANs for public IPs; this scenario is more common in internal infrastructure.

Yes. If a user proceeds past the browser warning, or if a non-browser client is configured to skip hostname verification, the TLS handshake completes with an unverified server identity. An attacker positioned as a network intermediary (e.g., on the same Wi-Fi segment or via BGP hijacking) can present their own certificate for that hostname and intercept all traffic.

Use the OpenSSL command: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'. This shows the SANs in the served certificate so you can verify they include the target hostname. Alternatively, curl -I https://yourdomain.com will report a certificate error if there is a mismatch.