Improper Following of a Certificate_s Chain of Trust

TLS certificate validation doesn't correctly walk the full chain from the presented certificate up to a trusted root - accepting a certificate signed by an intermediate that isn't itself properly validated, or trusting a self-signed certificate presented mid-chain without verifying it actually links back to a legitimately trusted root authority.

Chain-validation logic lives in the TLS client configuration, not the server being scanned - testing it properly means presenting a deliberately malformed certificate chain to the client and observing whether validation correctly rejects it, a test of the client's TLS stack rather than the target server.

TLS client library configuration review, and testing outbound TLS connections against deliberately malformed certificate chains to confirm proper validation.

Tip: This class is typically found by intercepting traffic with a controlled proxy and observing whether the client actually rejects an invalid, expired, wrong-hostname, or revoked certificate — a passive traffic capture on a supposedly encrypted internal link is the other common discovery path, for the plaintext-transport variant specifically.

Real-World Impact

Man-in-the-middle exposure, broken certificate-chain validation, and credentials sent over an unprotected transport all share the same underlying failure: the connection isn't actually providing the confidentiality and authenticity guarantee the application assumes it is. An attacker positioned on the network path, a compromised Wi-Fi access point, a malicious proxy, a rogue router, can intercept or tamper with traffic that the application believes is safely encrypted end-to-end.

Once that trust assumption is broken, everything the connection carries is exposed: credentials, session tokens, and any sensitive data moving in either direction, with no obvious indication to the user that anything is wrong, since a partially-broken TLS setup can still display as "secure" in a browser depending on exactly what failed.

Certificate-revocation checking gaps are a related but narrower failure: even a properly-validated certificate chain doesn't help if the client never checks whether a certificate was revoked after a private key compromise, which means a stolen and revoked certificate can still be accepted as valid.

Prevention and Secure Design

Preventing Improper Following of a Certificate_s Chain of Trust takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Enforce TLS everywhere, with no fallback to plaintext. Every connection carrying credentials or sensitive data — including internal, service-to-service traffic — should require TLS with no unencrypted fallback path.

Validate the full certificate chain, hostname, and revocation status. Chain trust alone isn't sufficient — confirm the hostname matches and check revocation status (OCSP or a current CRL) rather than assuming a presented certificate is still valid just because it was once issued correctly.

Use HSTS to prevent protocol downgrade. HTTP Strict Transport Security tells browsers to never attempt an unencrypted connection to your domain, closing off a common downgrade-attack vector.

Never disable certificate or transport validation, even temporarily. A validation bypass added for debugging or local development is one of the most common ways this class ends up shipped to production.

Pin certificates for high-value, first-party connections. For a mobile app or service talking to its own backend, pinning adds a layer beyond standard CA trust, at the cost of needing a clear certificate-rotation plan.