Improper Check for Certificate Revocation
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
An improper check for certificate revocation is a far more serious flaw than related certificate failures. This is because the use of any revoked certificate is almost certainly malicious. The most common reason for certificate revocation is compromise of the system in question, with the result that no legitimate servers will be using a revoked certificate, unless they are sorely out of sync.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
The following OpenSSL code ensures that there is a certificate before continuing execution.
Because this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The product could be communicating with a malicious host.
Weaknesses in this category are related to access control.
Weaknesses in this category are related to the design and architecture of a system's identification management components. Frequently these deal with verifying that ex...
This category identifies Software Fault Patterns (SFPs) within the Digital Certificate cluster.
This view (slice) covers all the elements in CWE.
This view contains a selection of weaknesses that represent the variety of weaknesses that are captured in CWE, at a level of abstraction that is likely to be useful t...
This view (slice) lists weaknesses that can be introduced during implementation.