CVE-2021-3450 Overview
CVE-2021-3450 is a certificate validation bypass vulnerability in OpenSSL that affects the X509_V_FLAG_X509_STRICT flag functionality. When this strict verification flag is enabled, an implementation error in the check for explicitly encoded elliptic curve parameters causes the result of a previous CA certificate validation check to be overwritten. This flaw effectively allows non-CA certificates to issue other certificates, potentially enabling man-in-the-middle attacks against TLS connections.
The vulnerability was introduced in OpenSSL version 1.1.1h when an additional strict check was added to disallow certificates with explicitly encoded elliptic curve parameters. The implementation error meant that when processing such certificates, the Boolean result confirming valid CA certificates was inadvertently overwritten, bypassing the CA validation entirely.
Critical Impact
This vulnerability enables attackers to use non-CA certificates to issue fraudulent certificates, potentially allowing man-in-the-middle attacks and impersonation of trusted services when applications explicitly set the X509_V_FLAG_X509_STRICT flag without proper purpose configuration.
Affected Products
- OpenSSL versions 1.1.1h through 1.1.1j
- FreeBSD 12.2 and related patch releases
- NetApp StorageGRID, Cloud Volumes ONTAP Mediator, and OnCommand Workflow Automation
- Tenable Nessus, Nessus Agent, and Nessus Network Monitor
- Oracle MySQL Server, WebLogic Server, GraalVM, and PeopleSoft Enterprise PeopleTools
- McAfee Web Gateway and Web Gateway Cloud Service
- SonicWall SMA100, Capture Client, Email Security, and SonicOS
- Node.js (multiple versions)
- Fedora 34
- Wind River Linux
Discovery Timeline
- March 25, 2021 - CVE-2021-3450 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2021-3450
Vulnerability Analysis
This vulnerability resides in OpenSSL's certificate chain validation logic, specifically within the implementation of the X509_V_FLAG_X509_STRICT verification flag. When enabled, this flag activates additional security checks on certificates in the verification chain, including a check introduced in version 1.1.1h to reject certificates with explicitly encoded elliptic curve parameters.
The vulnerability occurs because the implementation of this new elliptic curve check incorrectly overwrites the return value from a preceding check that verifies whether certificates in the chain are valid Certificate Authority (CA) certificates. This overwrite effectively bypasses the fundamental security constraint that only CA certificates should be allowed to issue other certificates.
In scenarios where a "purpose" is configured for certificate verification, a subsequent check provides an opportunity to catch this bypass. The default libssl client and server verification routines set a purpose, which mitigates the issue in standard TLS configurations. However, applications that explicitly set X509_V_FLAG_X509_STRICT while either not configuring a purpose or overriding the default purpose become vulnerable.
Root Cause
The root cause is a logic error in the certificate chain verification code where the result of the CA certificate validation check is stored in a variable that is subsequently overwritten by the elliptic curve parameter check. This violates the principle of maintaining independent verification results and represents a CWE-295 (Improper Certificate Validation) weakness. The fix requires preserving the CA validation result separately from other check results.
Attack Vector
An attacker can exploit this vulnerability through a network-based attack by presenting a maliciously crafted certificate chain to a vulnerable application. The attack requires the target application to meet specific conditions: it must use OpenSSL 1.1.1h through 1.1.1j, explicitly enable the X509_V_FLAG_X509_STRICT flag, and either not set a verification purpose or override the default purpose.
In a successful attack scenario, an attacker could use a legitimate end-entity certificate (not a CA certificate) to sign and issue fraudulent certificates for arbitrary domains. When presented to a vulnerable application, this forged certificate chain would pass validation, enabling man-in-the-middle attacks where the attacker can intercept and modify encrypted communications.
The attack complexity is considered high because exploitation requires the application to be configured in a specific non-default manner. However, the impact is severe as successful exploitation completely compromises the confidentiality and integrity of TLS communications.
Detection Methods for CVE-2021-3450
Indicators of Compromise
- Unusual certificate chains containing non-CA certificates in intermediate positions during TLS handshakes
- Certificate validation errors or warnings in application logs followed by successful connections that should have failed
- Network traffic patterns suggesting man-in-the-middle positioning, particularly for services using strict certificate validation
- Presence of certificates with explicitly encoded elliptic curve parameters in captured traffic
Detection Strategies
- Audit applications for use of X509_V_FLAG_X509_STRICT flag combined with custom or missing purpose configurations
- Monitor OpenSSL version inventories across all systems to identify installations running versions 1.1.1h through 1.1.1j
- Implement network monitoring to detect certificate chain anomalies and unexpected certificate issuers
- Review application configurations to identify any that override default SSL/TLS verification purposes
Monitoring Recommendations
- Enable verbose logging for SSL/TLS certificate verification in critical applications
- Deploy network intrusion detection signatures to identify anomalous certificate chain presentations
- Monitor for updates and patches from vendors of products that embed OpenSSL, particularly those listed in affected products
- Establish baseline certificate chain patterns for critical services to detect deviations
How to Mitigate CVE-2021-3450
Immediate Actions Required
- Upgrade OpenSSL to version 1.1.1k or later immediately on all affected systems
- Review all applications using OpenSSL to determine if they use the X509_V_FLAG_X509_STRICT flag
- Ensure all TLS client and server implementations have proper purpose configurations set
- Contact vendors of affected products (Oracle, NetApp, Tenable, SonicWall, etc.) to obtain updated versions
Patch Information
OpenSSL has released version 1.1.1k which addresses this vulnerability. The fix ensures that the CA certificate validation result is properly preserved and not overwritten by subsequent checks. Organizations should upgrade to OpenSSL 1.1.1k or later to fully remediate this vulnerability. The OpenSSL Security Advisory provides complete details on the fix.
Multiple downstream vendors have released patches for their affected products:
- Oracle Critical Patch Updates for April 2021 and subsequent quarters
- Tenable Security Notices TNS-2021-05, TNS-2021-08, and TNS-2021-09
- SonicWall Vulnerability Advisory SNWLID-2021-0013
- NetApp Advisory NTAP-20210326-0006
- FreeBSD Security Advisory FreeBSD-SA-21:07
Workarounds
- If immediate patching is not possible, ensure a verification purpose is always set when using X509_V_FLAG_X509_STRICT
- Disable the X509_V_FLAG_X509_STRICT flag temporarily until patching can be completed, accepting reduced strict checking
- Implement additional certificate validation at the application layer as a defense-in-depth measure
- Use network segmentation to limit exposure of vulnerable systems until patching is complete
# Check OpenSSL version on Linux systems
openssl version -a
# Example: Verify if installed version is vulnerable (1.1.1h through 1.1.1j)
# If output shows 1.1.1h, 1.1.1i, or 1.1.1j, system is vulnerable
# Upgrade to 1.1.1k or later
# On Debian/Ubuntu systems
sudo apt update && sudo apt install --only-upgrade openssl
# On RHEL/CentOS systems
sudo yum update openssl
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

