OpenSSL CVE-2024-12797 — Raw Public Key TLS Authentication Bypass Patched

OpenSSL CVE-2024-12797 — What Was Patched

The OpenSSL project published a security advisory on February 11, 2025 disclosing CVE-2024-12797, a high-severity authentication flaw that affects TLS clients using Raw Public Keys (RPKs, defined in RFC 7250) to authenticate the server. The vulnerability was reported to the project by Apple Inc. on December 18, 2024 and the fix was developed by Viktor Dukhovni of the OpenSSL core team.

According to the OpenSSL advisory, clients using RFC 7250 Raw Public Keys to authenticate a server may fail to notice that the server was not authenticated, because handshakes do not abort as expected when the SSL_VERIFY_PEER verification mode is set. In effect, a TLS client that requested peer verification and received an unverifiable RPK would proceed with the handshake as if authentication had succeeded — opening the connection to a man-in-the-middle attacker who is in a position to intercept the traffic.

Affected and Fixed Versions

The flaw affects OpenSSL 3.2, 3.3, and 3.4. Patched releases are:

• OpenSSL 3.4.1 (fix for the 3.4 branch)
• OpenSSL 3.3.3 (fix for the 3.3 branch)
• OpenSSL 3.2.4 (fix for the 3.2 branch)

OpenSSL 3.0 and 3.1 are not affected because RPK support was added in 3.2. OpenSSL 1.1.1 is also not affected. The advisory also states that the FIPS modules in 3.4, 3.3, 3.2, 3.1, and 3.0 are not affected.

Real-World Exposure

Raw Public Keys are not used by typical web TLS, where servers present X.509 certificates. RPK adoption is concentrated in IoT deployments, constrained-device protocols, and a subset of newer TLS-based application protocols where the certificate-authority model adds unwanted overhead. If your applications rely solely on the standard certificate path through the SSL_VERIFY_PEER mode, the practical exposure is low, but the patched version should still be installed because OpenSSL is shared across many processes on a typical server.

If your stack explicitly enables RPK authentication — anywhere in your code, your library configuration, or in middleware that wraps OpenSSL — treat the exposure as immediate and patch first.

What to Do

Update OpenSSL via your distribution's package manager and restart every service that links against the library. On Debian and Ubuntu, run apt-get update followed by apt-get upgrade openssl libssl3. On RHEL, AlmaLinux, Rocky, and Amazon Linux, run dnf update openssl. After the package update, services that hold a long-lived OpenSSL handle in memory continue to use the old library version until they are restarted; tools such as needrestart on Debian/Ubuntu identify which services still need a restart.

For container images, rebuild base layers so the patched OpenSSL package is pulled in, then redeploy. Image scanners such as Trivy and Grype detect the affected versions automatically once their advisory feeds are refreshed.

Verify the running library with openssl version, and confirm the package metadata matches the patched release for your distribution. The OpenSSL project's security mailing list and the vulnerabilities page on openssl-library.org publish each advisory as it is released and remain the authoritative source for follow-up fixes.