Improper Check for Certificate Revocation

The application validates a TLS/X.509 certificate's signature and expiration but doesn't check whether the certificate has been revoked (via CRL or OCSP) since issuance - accepting a certificate that its own issuing authority has since declared compromised or invalid, most dangerous when the original private key behind that certificate has been stolen and the certificate revoked specifically because of that.

Whether revocation checking is actually performed is a client-side (or client-library) TLS-validation configuration detail - testing it properly requires presenting a genuinely revoked certificate to the validating client and observing whether it's rejected, which needs a real revoked-certificate test fixture rather than a generic probe against the live target.

TLS client configuration review, checking that OCSP or CRL checking is enabled and enforced (not merely soft-fail) in whatever HTTP client or library makes outbound TLS connections on the application's behalf.

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 Check for Certificate Revocation 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.