logo

Improper Certificate Validation

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application fails to properly verify the authenticity of a digital certificate, or performs the verification incorrectly, allowing untrusted connections to appear legitimate.

This vulnerability occurs when an application fails to properly verify the authenticity of a digital certificate, or performs the verification incorrectly, allowing untrusted connections to appear legitimate.
Extended Description

Digital certificates act like digital passports for servers and services, proving their identity. When an application doesn't rigorously check these certificates—for example, by accepting self-signed certificates, ignoring expiration dates, or not validating the certificate chain back to a trusted root—it can mistakenly connect to a malicious server impersonating a legitimate one. This creates a critical opening for man-in-the-middle (MitM) attacks where attackers can intercept, read, or modify sensitive data in transit. To prevent this, developers must ensure their code enforces strict certificate validation. This means always verifying the certificate's signature chain against a trusted root certificate authority (CA), checking the hostname matches, and ensuring the certificate is valid and not revoked. Relying on default settings is often insufficient; explicit configuration in libraries for TLS/SSL connections is typically required to reject invalid certificates and maintain a secure communication channel.
Common Consequences 1
Scope: IntegrityAuthentication

Impact: Bypass Protection MechanismGain Privileges or Assume Identity

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.
Detection Methods 7
Automated Static Analysis - Binary or BytecodeSOAR Partial
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
Manual Static Analysis - Binary or BytecodeSOAR Partial
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
Dynamic Analysis with Automated Results InterpretationSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Web Application Scanner
Dynamic Analysis with Manual Results InterpretationHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Man-in-the-middle attack tool
Manual Static Analysis - Source CodeHigh
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)
Automated Static Analysis - Source CodeSOAR Partial
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
Architecture or Design ReviewHigh
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.)
Potential Mitigations 2
Phase: Architecture and DesignImplementation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Phase: 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.
Demonstrative Examples 5

ID : DX-121

This code checks the certificate of a connected peer.

Code Example:

Bad
C
c

// 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.

ID : DX-122

The following OpenSSL code obtains a certificate and verifies it.

Code Example:

Bad
C
c

// 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.

ID : DX-123

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

Code Example:

Bad
C
c

//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.

ID : DX-124

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

Code Example:

Bad
C
c

// 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.

ID : DX-125

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

Code Example:

Bad
C
c

// got certificate, host can be trusted*

c
Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.
Observed Examples 20
CVE-2019-12496A Go framework for robotics, drones, and IoT devices skips verification of root CA certificates by default.
CVE-2014-1266chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). Incorrect Control Flow Scoping (Incorrect Control Flow Scoping) -> Dead Code (Dead Code) -> Improper Certificate Validation (Improper Certificate Validation) -> Return of Wrong Status Code (Return of Wrong Status Code) -> Channel Accessible by Non-Endpoint (Channel Accessible by Non-Endpoint).
CVE-2021-22909Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (Improper Certificate Validation), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (Download of Code Without Integrity Check).
CVE-2008-4989Verification function trusts certificate chains in which the last certificate is self-signed.
CVE-2012-5821Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA)
CVE-2009-3046Web browser does not check if any intermediate certificates are revoked.
CVE-2011-0199Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
CVE-2012-5810Mobile banking application does not verify hostname, leading to financial loss.
CVE-2012-3446Cloud-support library written in Python uses incorrect regular expression when matching hostname.
CVE-2009-2408Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
CVE-2012-2993Smartphone device does not verify hostname, allowing spoofing of mail services.
CVE-2012-5822Application uses third-party library that does not validate hostname.
CVE-2012-5819Cloud storage management application does not validate hostname.
CVE-2012-5817Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
CVE-2010-1378chain: incorrect calculation allows attackers to bypass certificate checks.
CVE-2005-3170LDAP client accepts certificates even if they are not from a trusted CA.
CVE-2009-0265chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
CVE-2003-1229chain: product checks if client is trusted when it intended to check if the server is trusted, allowing validation of signed code.
CVE-2002-0862Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
CVE-2009-1358chain: OS package manager does not check properly check the return value, allowing bypass using a revoked certificate.
References 3
Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben
16-10-2012
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf
ID: REF-243
Computer Security: Art and Science
M. Bishop
Addison-Wesley
2003
ID: REF-244
State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation
Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, and Rama S. Moorthy
07-2014
https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx(2025-09-05)
ID: REF-1479
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Mobile : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Implementation
Related Attack Patterns
Related Weaknesses
ChildOf: Improper Authentication (CWE-287)
ChildOf: Improper Authentication (CWE-287)
PeerOf: Key Exchange without Entity Authentication (CWE-322)
Taxonomy Mapping
  • OWASP Top Ten 2004