Skip to content

CWE-297: Improper Certificate Validation (Host Mismatch)

Overview

This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected that the application accepted TLS/SSL certificates where the hostname in the certificate doesn't match the actual hostname being accessed. Evidence includes successful HTTPS connections despite CN/SAN mismatches, or the application accepting certificates issued for different domains when making backend API calls. This is typically observed when testing the application's outbound HTTPS requests.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

When reviewing your security scan results, you'll see:

HTTP Request Details

  • URL and endpoint that triggered the finding
  • HTTP method (GET, POST, etc.)
  • Query parameters or form data with test payloads
  • Request headers and body content

HTTP Response Evidence

  • Response showing the vulnerability manifestation
  • Evidence that hostname verification was not enforced
  • Runtime behavior indicators

Attack Vector

  • Which parameter or input is vulnerable
  • Type of exploitation possible
  • Context where the vulnerability appears

Mapping DAST Findings to Source Code

Find the Vulnerable Endpoint

Search for HTTPS connections with hostname issues:

# Search for HTTP client code
grep -r "https://" src/
grep -r "SSLContext" src/
grep -r "HostnameVerifier" src/
grep -r "check_hostname" src/

Locate Certificate/Hostname Validation

Common patterns to search for:

  • Python: ssl.create_default_context(), check_hostname=False
  • Node.js: servername option, SNI configuration
  • Java: HostnameVerifier, SSLSocketFactory
  • C#/.NET: ServerCertificateValidationCallback, hostname checks
  • PHP: CURLOPT_SSL_VERIFYHOST

Find Hostname Verification

Search for disabled hostname checks:

# Find disabled hostname verification
grep -r "check_hostname.*False" src/
grep -r "HostnameVerifier" src/
grep -r "CURLOPT_SSL_VERIFYHOST.*0" src/

Trace to Vulnerable Configuration

Look for hostname validation issues:

  • Disabled hostname check: check_hostname=False, VERIFYHOST=0
  • Wildcard misuse: Accepting *.example.com for evil.com
  • IP address certificates: Using IPs instead of domains
  • Custom validators: Accepting any hostname
  • Missing SNI: Server Name Indication not configured

Remediation

Core Principle: Never establish a TLS connection unless the certificate’s hostname is validated against the requested peer identity by the TLS stack; applications must not bypass or weaken hostname verification.

→ For comprehensive remediation guidance, see Static CWE-297 Guidance

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Check for disabled hostname verification
grep -r "check_hostname.*False" src/
grep -r "CURLOPT_SSL_VERIFYHOST.*0" src/

# Test hostname mismatch
curl https://wrong.host.badssl.com/  # Should fail

Verify the Fix

  • Confirm hostname verification enabled
  • Verify certificate CN/SAN matches requested hostname
  • Check SNI properly configured
  • Ensure wildcard certificates validated correctly
  • Test that hostname mismatches are rejected

Test Edge Cases

# Hostname mismatch should fail
openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com

# Wildcard certificate validation
# Valid: *.example.com matches api.example.com
# Invalid: *.example.com does NOT match sub.api.example.com

# IP addresses in certificates
curl https://192.168.1.1/  # Should have proper SAN with IP

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources