Skip to content

CWE-299: Improper Check for Certificate Revocation

Overview

Improper certificate revocation checking occurs when an application validates a certificate chain but fails to determine whether any certificate in that chain has been revoked. A revoked certificate may have been compromised, misissued, replaced, or administratively invalidated before its normal expiration date. If an application accepts revoked certificates, attackers may be able to continue using a certificate that the issuer has explicitly withdrawn.

Revocation checking is separate from hostname validation, expiration validation, trust-chain validation, and Basic Constraints validation. A certificate can pass all of those checks and still be unsafe to trust if the certificate authority has revoked it.

OWASP Classification

A07:2025 - Authentication Failures

Risk

High: Accepting revoked certificates can enable man-in-the-middle attacks, impersonation of trusted services, and continued use of compromised client or server certificates. The risk is highest for mutual TLS, private PKI, high-trust service-to-service communication, and systems that use certificates for authorization decisions.

Remediation Steps

Core principle: Validate certificate revocation status as part of certificate path validation, using OCSP, OCSP stapling, CRLs, or a managed TLS stack with an explicit revocation policy.

Use a TLS Stack with Revocation Checking Configured

Do not assume revocation checking is enabled just because certificate validation is enabled. Verify how your framework, runtime, reverse proxy, or operating system TLS stack handles revocation.

Common implementation options:

  • OCSP stapling validation for public web certificates
  • OCSP requests to the certificate authority responder
  • Certificate Revocation Lists (CRLs), especially for private PKI
  • Managed load balancers, service meshes, or gateways with revocation policy configured centrally
  • Short-lived certificates combined with automated rotation where revocation is operationally impractical

Validate the Whole Chain

Check revocation status for the leaf certificate and relevant intermediate certificates, not only the server certificate presented first.

Validation should include:

  • Certificate chain builds to a trusted root
  • Hostname or identity matches the expected peer
  • Certificate is within its validity period
  • Key usage and extended key usage are appropriate
  • Revocation status is checked for certificates that can be revoked

Avoid Incomplete Custom Certificate Callbacks

Custom certificate validation often introduces CWE-299 when it performs only a subset of TLS checks:

VULNERABLE pattern:
- Build certificate chain
- Check hostname
- Ignore OCSP/CRL status
- Return success

If you must customize certificate validation, delegate chain validation and revocation policy to a mature TLS or PKIX library wherever possible. Do not replace the platform verifier with ad hoc checks.

Configure Fail-Closed Behavior for High-Trust Use Cases

Decide what the application should do when revocation status cannot be determined.

For high-trust systems such as mTLS, administrative APIs, payment flows, and private PKI, prefer fail-closed behavior: reject the certificate if revocation status is unavailable or stale. For lower-risk public web browsing scenarios, some platforms use soft-fail behavior because OCSP responders can be unavailable. Document the policy explicitly instead of relying on defaults.

Java PKIX Revocation Checking Example

CertificateFactory cf = CertificateFactory.getInstance("X.509");
CertPath certPath = cf.generateCertPath(peerCertificates);

PKIXParameters params = new PKIXParameters(trustAnchors);
params.setRevocationEnabled(true);

CertPathValidator validator = CertPathValidator.getInstance("PKIX");
validator.validate(certPath, params);

For stricter policies, configure a PKIXRevocationChecker with the OCSP or CRL behavior required by your environment, and test that revoked certificates are rejected.

Test Revocation Handling

Verify the implementation with controlled certificates:

  • A valid non-revoked certificate is accepted
  • A revoked leaf certificate is rejected
  • A revoked intermediate certificate is rejected
  • An unavailable OCSP responder or missing CRL behaves according to policy
  • Cached revocation responses expire and refresh correctly

Additional Resources