Skip to content

CWE-296: Improper Certificate Validation (Trust Chain)

Overview

This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected that the application failed to properly validate certificate trust chains when establishing TLS/SSL connections. Evidence includes acceptance of certificates not signed by trusted CAs, incomplete chain validation, or successful connections despite invalid intermediate certificates. The scanner may intercept HTTPS traffic using untrusted certificates and observe that the application proceeds without validation errors.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

The scanner observed that the application successfully established a TLS connection despite:

  • An invalid or untrusted certificate chain
  • Missing or incorrect intermediate certificates
  • A self-signed certificate
  • Hostname mismatch
  • A certificate signed by an untrusted CA

This indicates that certificate chain validation is disabled, bypassed, or misconfigured.

Note: Some scanners flag CWE-296 when corporate proxies or test environments use custom CAs. Ensure the behavior is not environment-specific before suppressing findings.

Mapping the Finding to Source Code

CWE-296 does not map to a specific HTTP endpoint or request parameter. Instead, it maps to outbound TLS client configuration.

Identify HTTPS Clients

Search for code that makes outbound HTTPS calls:

  • HTTP client libraries
  • REST clients
  • SDKs for third-party APIs
  • OAuth / OpenID clients
  • Webhook callbacks

Examples to search for:

# Java
grep -r "HttpsURLConnection" .
grep -r "SSLContext" .
grep -r "TrustManager" .
grep -r "RestTemplate" .

# Node.js
grep -r "https.request" .
grep -r "rejectUnauthorized" .

# Python
grep -r "verify=False" .
grep -r "ssl.create_default_context" .

# .NET
grep -r "HttpClientHandler" .
grep -r "ServerCertificateCustomValidationCallback" .

Remediation

Core principle: Never establish a TLS connection unless the peer’s certificate chain and hostname are validated against a trusted root store by the TLS stack; applications must not bypass or replace trust chain validation logic.

  • Enforce Proper Certificate Chain Validation Ensure your TLS client:

    • Validates the full certificate chain
    • Trusts only approved root CAs
    • Verifies hostnames correctly
    • Rejects self-signed or invalid certificates (unless explicitly required)
  • Common Fixes
    • Remove "trust-all" trust managers
    • Remove verify=False
    • Enable hostname verification
    • Use the platform's default trust store
    • Properly install intermediate certificates
    • Implement certificate pinning correctly (if used)

What NOT to Do

  • Do not disable validation "temporarily"
  • Do not accept all certificates in production
  • Do not suppress TLS validation errors

Verify the Fix

  • Re-run the DAST scan
  • Attempt connection using:
    • self-signed certificates
    • invalid chains
    • hostname mismatches
  • Confirm TLS handshake fails as expected

Additional Resources