Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.4)  

CWE-296: Improper Following of a Certificate's Chain of Trust

Weakness ID: 296
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
+ Extended Description

If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.

In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.

There are several ways in which the chain of trust might be broken, including but not limited to:

  • Any certificate in the chain is self-signed, unless it the root.
  • Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.
  • An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.
  • The root certificate has been compromised or authorized to the wrong party.
+ Relationships

The table(s) below 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" (CWE-1000)
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfBaseBase - 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.295Improper Certificate Validation
PeerOfVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
+ Relevant to the view "Software Development" (CWE-699)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
+ Relevant to the view "Architectural Concepts" (CWE-1008)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify Actors
+ Modes Of Introduction

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

Architecture and DesignREALIZATION: This weakness is caused during implementation of an architectural security tactic.
ImplementationWhen the software 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
The listings below show 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.


Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

The table below 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.


Technical Impact: Hide Activities

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.
Access Control

Technical Impact: Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands

Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.
+ Likelihood Of Exploit
+ Demonstrative Examples

Example 1

This code checks the certificate of a connected peer.

(bad code)
Example Language:
if ((cert = SSL_get_peer_certificate(ssl)) && host)

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 a MITM attack to modify the traffic from server to client.

+ Observed Examples
Server allows bypass of certificate pinning by sending a chain of trust that includes a trusted CA that is not pinned.
Verification function trusts certificate chains in which the last certificate is self-signed.
Chain: 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.
chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
chain: incorrect check of return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
File-transfer software does not validate Basic Constraints of an intermediate CA-signed certificate.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that proper certificate checking is included in the system design.

Phase: Implementation

Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.

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 full chain of trust.
+ Memberships
This 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.
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to follow chain of trust in certificate validation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <>.
[REF-245] Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25. <>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, References, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Follow Chain of Trust in Certificate Validation
2013-02-21Improper Following of Chain of Trust for Certificate Validation
More information is available — Please select a different filter.
Page Last Updated: March 15, 2021