CWE-297: Improper Validation of Certificate with Host Mismatch
Overview
Improper certificate hostname validation occurs when TLS/SSL clients don't verify the certificate's Common Name (CN) or Subject Alternative Name (SAN) matches the hostname being connected to, enabling man-in-the-middle attacks by allowing attackers to present valid certificates for different domains.
OWASP Classification
A07:2025 - Authentication Failures
Risk
High: Missing hostname validation enables MITM attacks (attacker uses valid cert for different domain), credential interception, data theft, session hijacking, and complete bypass of TLS security since any valid certificate is accepted regardless of hostname.
Remediation Steps
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.
Locate the hostname validation vulnerability in your code
- Review the flaw details to identify the specific file, line number, and code pattern
- Look for TLS/SSL client code making HTTPS requests or establishing secure connections
- Identify where hostname verification might be disabled: SSL_VERIFY_NONE, check_hostname=False, custom validators
- Trace the connection establishment code to verify certificate validation configuration
Always verify hostname (Primary Defense)
- Use default SSL/TLS libraries with verification enabled: Most libraries enable hostname verification by default (requests, urllib3, OkHttp, HttpClient)
- Never disable hostname verification: Remove SSL_VERIFY_NONE, CERT_NONE, check_hostname=False, or custom validators that skip hostname checks
- Check CN and SAN fields match expected hostname: Ensure library verifies certificate's Common Name and Subject Alternative Names against the hostname
- Use library's built-in hostname verification: Don't implement custom certificate validation unless absolutely necessary
Use secure TLS configuration
- Don't set SSL_VERIFY_NONE or equivalent: Remove insecure settings like
verify=False(Python),SSL_VERIFY_NONE(OpenSSL),setHostnameVerifier(ALLOW_ALL)(Java) - Don't implement custom certificate validation: Custom validators often have security flaws; use library defaults
- Use system certificate stores: Rely on OS-managed trusted CA certificates
- Enable strict certificate checking: Verify entire certificate chain, not just leaf certificate
Handle certificate errors properly
- Fail on certificate validation errors: Don't catch and ignore SSL exceptions; let the connection fail
- Don't ignore SSL warnings/errors: Treat certificate validation failures as critical security issues
- Log certificate validation failures: Record hostname, certificate details, and error message for investigation
- Alert on repeated failures: Monitor for potential MITM attacks indicated by frequent certificate errors
Pin certificates for critical connections (Defense in Depth)
- Pin expected certificates or public keys for high-security connections
- Validate against pinned values in addition to normal hostname verification
- Update pins during certificate rotation (implement backup pins for smooth rotation)
- Use certificate transparency logs to detect mis-issued certificates
Test the hostname verification fix
- Verify connections fail when certificate hostname doesn't match
- Test with self-signed certificates (should fail unless explicitly trusted)
- Test with expired certificates (should fail)
- Test with valid certificate for different domain (should fail)
- Use SSL testing tools to verify proper configuration
- Re-scan with security scanner to confirm the issue is resolved
Dynamic Scan Guidance
For guidance on remediating this CWE when detected by dynamic (DAST) scanners:
- Dynamic Scan Guidance - Analyzing DAST findings and mapping to source code
Common Vulnerable Patterns
- SSL_VERIFY_NONE / CERT_NONE
- check_hostname=False
- Ignoring HostnameVerifier errors
- Custom validators that skip hostname check
- Accepting any valid certificate