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 certificate may be revoked before its normal expiration date because it was compromised, misissued, replaced, or administratively invalidated, and an application that does not check keeps trusting it regardless.

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.

Relationship to Other CWEs

CWE-299 (this page) - revocation: the chain validates and the certificate is in date, but nothing determines whether any certificate in that chain has been withdrawn since it was issued.
CWE-295 (Improper Certificate Validation) - the parent MITRE records for this page and for the other certificate checks listed here. Use it when validation is switched off wholesale rather than failing one specific check; the language-specific pages live there.
CWE-296 (Improper Following of a Certificate's Chain of Trust) - the chain: the certificate does not lead to a trusted root, whether it is self-signed, signed by an untrusted CA, or missing a valid intermediate.
CWE-297 (Improper Validation of Certificate with Host Mismatch) - the name: the chain is valid but nothing checks that the certificate identifies the host being connected to. Chain and name are separate checks, and a client can pass one while failing the other.
CWE-298 (Improper Validation of Certificate Expiration) - the dates: the certificate is accepted outside the validity window its issuer set. Expiry is the end date the issuer scheduled; revocation is the issuer withdrawing the certificate before it.
CWE-370 (Missing Check for Certificate Revocation after Initial Check) - MITRE records this as a child of this page: revocation is checked once and never rechecked, so a long-lived connection or a cached result goes on trusting a certificate revoked since. No page here.

OWASP Classification

A07:2025 - Authentication Failures

Risk

High: A certificate the issuer has withdrawn still passes validation, so whoever holds it can go on impersonating the service or client it names. 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 this weakness 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. 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.

Check Where Your TLS Stack Stands by Default

Path-validation APIs and TLS stacks tend to differ here, and the difference is easy to miss: a library that validates a certificate chain on request usually checks revocation as part of the PKIX algorithm, while the same platform's TLS client often does not unless it is switched on. Establish which of the two your code actually goes through before concluding the check is happening.

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

Language-Specific Guidance

Java - why JSSE and the PKIX path API disagree by default, PKIXRevocationChecker options, and the hard-fail/soft-fail decision