CWE - CWE-295: Improper Certificate Validation (4.19.1)
Home > CWE List > CWE-295: Improper Certificate Validation (4.19.1)  
ID
  • Home
  • Who We Are User Stories History Documents Videos
  • Basics
    Root Cause Mapping   ►
    Guidance Quick Tips Examples
    How to Contribute Weakness Content FAQs Glossary
  • Top-N Lists   ►
    Top 25 Software Top Hardware Top 10 KEV Weaknesses
    CWE List   ►
    Current Version Reports Visualizations Releases Archive
    Downloads REST API
  • News   ►
    Current News Blog Podcast News Archive
    CWE Board Working Groups & Special Interest Groups Email Lists
  • Search CWE List Search Website

    CWE-295: Improper Certificate Validation

    Weakness ID: 295
    Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
    Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
    View customized information:
    For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
    ×

    Edit Custom Filter


    + Description
    The product does not validate, or incorrectly validates, a certificate. Diagram for CWE-295
    + Common Consequences
    Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
    Impact Details

    Bypass Protection Mechanism; Gain Privileges or Assume Identity

    		Scope: Integrity, Authentication

    When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.
    + Potential Mitigations
    Phase(s) Mitigation

    Architecture and Design; Implementation
    Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

    Implementation
    If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.
    + Relationships
    Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
    + Relevant to the view "Research Concepts" (View-1000)
    Nature Type ID Name
    ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
    ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 296 Improper Following of a Certificate's Chain of Trust
    ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 297 Improper Validation of Certificate with Host Mismatch
    ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 298 Improper Validation of Certificate Expiration
    ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 299 Improper Check for Certificate Revocation
    ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 599 Missing Validation of OpenSSL Certificate
    PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 322 Key Exchange without Entity Authentication
    + Relevant to the view "Software Development" (View-699)
    Nature Type ID Name
    MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
    + Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
    Nature Type ID Name
    ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
    + Relevant to the view "Architectural Concepts" (View-1008)
    Nature Type ID Name
    MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1014 Identify Actors
    + Background Details
    A certificate is a token that associates an identity (principal) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner.
    + Modes Of Introduction
    Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
    Phase Note
    Architecture and Design
    Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
    Implementation When the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.
    + Applicable Platforms
    Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
    Languages

    Class: Not Language-Specific (Undetermined Prevalence)

    Technologies

    Class: Not Technology-Specific (Undetermined Prevalence)

    Class: Web Based (Undetermined Prevalence)

    Class: Mobile (Undetermined Prevalence)

    + Demonstrative Examples

    Example 1


    This code checks the certificate of a connected peer.

    (bad code)
    Example Language: C 
    if ((cert = SSL_get_peer_certificate(ssl)) && host)
    foo=SSL_get_verify_result(ssl);

    if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))

    // certificate looks good, host can be trusted

    In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using an Adversary-in-the-Middle (AITM) attack to modify the traffic from server to client.



    Example 2


    The following OpenSSL code obtains a certificate and verifies it.

    (bad code)
    Example Language: C 
    cert = SSL_get_peer_certificate(ssl);
    if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) {

    // do secret things
    }

    Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.



    Example 3


    The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates.

    (bad code)
    Example Language: C 
    if (cert = SSL_get_peer(certificate(ssl)) {
    foo=SSL_get_verify_result(ssl);
    if ((X509_V_OK==foo) || (X509_V_ERR_CERT_HAS_EXPIRED==foo))

    //do stuff

    If the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.



    Example 4


    The following OpenSSL code ensures that there is a certificate before continuing execution.

    (bad code)
    Example Language: C 
    if (cert = SSL_get_peer_certificate(ssl)) {

    // got a certificate, do secret things

    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 software could be communicating with a malicious host.



    Example 5


    The following OpenSSL code ensures that the host has a certificate.

    (bad code)
    Example Language: C 
    if (cert = SSL_get_peer_certificate(ssl)) {

    // got certificate, host can be trusted

    //foo=SSL_get_verify_result(ssl);

    //if (X509_V_OK==foo) ...
    }

    Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.



    + Selected Observed Examples

    Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

    Reference Description
    A Go framework for robotics, drones, and IoT devices skips verification of root CA certificates by default.
    Chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint). The code's whitespace indentation did not reflect the actual control flow (CWE-1114) and did not explicitly delimit the block (CWE-483), which could have made it more difficult for human code auditors to detect the vulnerability.
    Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
    Verification function trusts certificate chains in which the last certificate is self-signed.
    Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA)
    Web browser does not check if any intermediate certificates are revoked.
    Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
    Mobile banking application does not verify hostname, leading to financial loss.
    Cloud-support library written in Python uses incorrect regular expression when matching hostname.
    Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
    Smartphone device does not verify hostname, allowing spoofing of mail services.
    Application uses third-party library that does not validate hostname.
    Cloud storage management application does not validate hostname.
    Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
    chain: incorrect calculation allows attackers to bypass certificate checks.
    LDAP client accepts certificates even if they are not from a trusted CA.
    chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
    chain: product checks if client is trusted when it intended to check if the server is trusted, allowing validation of signed code.
    Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
    chain: OS package manager does not check properly check the return value, allowing bypass using a revoked certificate.
    + Weakness Ordinalities
    Ordinality Description
    Primary
    (where the weakness exists independent of other weaknesses)
    + Detection Methods
    Method Details

    Automated Static Analysis - Binary or Bytecode

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Cost effective for partial coverage:
    • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
    • Binary Weakness Analysis - including disassembler + source code weakness analysis

    Effectiveness: SOAR Partial

    Manual Static Analysis - Binary or Bytecode

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Cost effective for partial coverage:
    • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

    Effectiveness: SOAR Partial

    Dynamic Analysis with Automated Results Interpretation

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Cost effective for partial coverage:
    • Web Application Scanner

    Effectiveness: SOAR Partial

    Dynamic Analysis with Manual Results Interpretation

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Highly cost effective:
    • Man-in-the-middle attack tool

    Effectiveness: High

    Manual Static Analysis - Source Code

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Highly cost effective:
    • Focused Manual Spotcheck - Focused manual analysis of source
    • Manual Source Code Review (not inspections)

    Effectiveness: High

    Automated Static Analysis - Source Code

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Cost effective for partial coverage:
    • Source code Weakness Analyzer
    • Context-configured Source Code Weakness Analyzer

    Effectiveness: SOAR Partial

    Architecture or Design Review

    According to SOAR [REF-1479], the following detection techniques may be useful:

    Highly cost effective:
    • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

    Effectiveness: High
    + Memberships
    Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
    Nature Type ID Name
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
    MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1382 ICS Operations (& Maintenance): Emerging Energy Technologies
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1442 OWASP Top Ten 2025 Category A07:2025 - Authentication Failures
    + Vulnerability Mapping Notes
    Usage ALLOWED
    (this CWE ID may be used to map to real-world vulnerabilities)
    Reason Acceptable-Use

    Rationale

    		This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

    Comments

    		Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
    + Taxonomy Mappings
    Mapped Taxonomy Name Node ID Fit Mapped Node Name
    OWASP Top Ten 2004 A10 CWE More Specific Insecure Configuration Management
    + References
    [REF-243] Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16.
    <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
    [REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
    [REF-1479] Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler and Rama S. Moorthy. "State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation". 2014-07.
    <https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx>. (URL validated: 2025-09-05)
    + Content History
    + Submissions
    Submission Date Submitter Organization
    2006-07-19
    (CWE Draft 3, 2006-07-19)     		CWE Community
    Submitted by members of the CWE community to extend early CWE versions
    + Modifications
    Modification Date Modifier Organization
    2025-12-11
    (CWE 4.19, 2025-12-11)     		CWE Content Team MITRE
    updated Applicable_Platforms, Observed_Examples, Relationships, Weakness_Ordinalities
    2025-09-09
    (CWE 4.18, 2025-09-09)     		CWE Content Team MITRE
    updated Common_Consequences, Description, Detection_Factors, Diagram, References
    2023-06-29 CWE Content Team MITRE
    updated Mapping_Notes
    2023-04-27 CWE Content Team MITRE
    updated Relationships
    2023-01-31 CWE Content Team MITRE
    updated Description, Modes_of_Introduction
    2022-10-13 CWE Content Team MITRE
    updated Observed_Examples, References
    2022-04-28 CWE Content Team MITRE
    updated Relationships
    2021-10-28 CWE Content Team MITRE
    updated Observed_Examples, Relationships
    2021-07-20 CWE Content Team MITRE
    updated Demonstrative_Examples, Observed_Examples
    2020-08-20 CWE Content Team MITRE
    updated Related_Attack_Patterns
    2020-02-24 CWE Content Team MITRE
    updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Relationships
    2019-09-19 CWE Content Team MITRE
    updated Demonstrative_Examples, Relationships
    2019-06-20 CWE Content Team MITRE
    updated Relationships
    2018-03-27 CWE Content Team MITRE
    updated Background_Details, Modes_of_Introduction, Potential_Mitigations, Relationships
    2017-11-08 CWE Content Team MITRE
    updated Modes_of_Introduction, References, Relationships
    2017-01-19 CWE Content Team MITRE
    updated Relationships
    2015-12-07 CWE Content Team MITRE
    updated Relationships
    2014-07-30 CWE Content Team MITRE
    updated Detection_Factors
    2014-06-23 CWE Content Team MITRE
    updated Observed_Examples
    2013-02-21 CWE Content Team MITRE
    updated Applicable_Platforms, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
    2012-12-28 CWE Content Team MITRE
    Converted from category to weakness class.
    2012-05-11 CWE Content Team MITRE
    updated Related_Attack_Patterns
    2008-10-14 CWE Content Team MITRE
    updated Background_Details, Description
    2008-09-08 CWE Content Team MITRE
    updated Relationships, Taxonomy_Mappings
    2008-08-15 Veracode
    Suggested OWASP Top Ten 2004 mapping
    + Previous Entry Names
    Change Date Previous Entry Name
    2013-02-21 Certificate Issues
    Page Last Updated: January 21, 2026