Executive Summary

This vulnerability is an Improper Certificate Validation issue in Erlang OTP's public_key modules, specifically in how TLS hostname verification is performed.

It allows a DNS nameConstraints bypass via fallback to the subject CommonName (CN) when no subjectAltName (SAN) is present in a certificate.

Two flaws combine: first, the validation only checks SAN DNS entries against nameConstraints, ignoring CN; second, hostname verification falls back to CN if SAN is missing, accepting certificates that should be restricted.

As a result, a subordinate CA with restricted DNS nameConstraints can issue a leaf certificate with no SAN but a CN that matches an out-of-scope hostname, and the OTP TLS client will accept it as valid.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker to present a TLS certificate that appears valid for a hostname it should not be valid for, bypassing DNS nameConstraints.

This can lead to man-in-the-middle attacks where an attacker intercepts or impersonates a trusted service by using a certificate issued by a subordinate CA with restricted nameConstraints.

It undermines the trust model of TLS connections, potentially exposing sensitive data or enabling unauthorized access.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability in Erlang OTP's certificate validation allows a DNS nameConstraints bypass via fallback to the subject CommonName (CN) during TLS hostname verification. This improper validation can lead to acceptance of certificates for out-of-scope hostnames, potentially enabling Man-in-the-Middle attacks or unauthorized interception of communications.

Such weaknesses in TLS certificate validation can undermine the confidentiality and integrity of data transmissions, which are critical requirements under common standards and regulations like GDPR and HIPAA. These regulations mandate strong protections for personal and sensitive data, including secure communications and proper authentication of endpoints.

By allowing bypasses in hostname verification, this vulnerability could lead to unauthorized data access or interception, thereby increasing the risk of non-compliance with these standards. Organizations relying on affected Erlang OTP versions without applying patches or mitigations may face challenges in meeting their regulatory obligations for secure communications.

The issue has been addressed by removing the CN fallback and enforcing strict hostname verification based solely on Subject Alternative Names (SANs), aligning with RFC 9525. Applying these fixes helps restore compliance with best practices for certificate validation required by security standards.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves improper certificate validation in Erlang OTP's public_key module, specifically a fallback to CommonName (CN) when Subject Alternative Names (SANs) are missing in TLS hostname verification.

Detection on your system would involve checking the version of Erlang OTP and the public_key application to see if they are within the affected versions (OTP 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1; public_key versions before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1).

Additionally, you can audit TLS connections made by your Erlang applications to check if certificates without SANs but with CNs are accepted, which would indicate vulnerability.

While no explicit commands are provided in the resources, a practical approach includes:

• Check Erlang/OTP and public_key versions installed on your system.
• Use Erlang shell commands to inspect the ssl application and public_key module versions.
• Monitor or log TLS handshake details to identify certificates accepted with CN-only names.
• Implement or enable ssl verify_fun option to reject certificates missing subjectAltName or with no domain name, as a detection and mitigation step.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include upgrading Erlang OTP and the public_key module to patched versions that fix this vulnerability.

• Upgrade OTP to versions 26.2.5.21, 27.3.4.12, 28.5.0.1, or 29.0.1 or later.
• Upgrade the public_key application to versions 1.15.1.7, 1.17.1.3, 1.20.3.1, or 1.21.1 or later.

If immediate upgrade is not possible, use the ssl application's verify_fun option to reject certificates that lack subjectAltName or have no domain name, effectively preventing acceptance of CN-only certificates.

This workaround enforces stricter certificate validation and reduces the risk of DNS nameConstraints bypass.

The vulnerability fix removes the fallback to CommonName in hostname verification, enforcing strict SAN-only checks as per RFC 9525.

Useful 0 Not Useful 0