OpenSSL 4.1.0 Beta 2 Ships, Pushing DTLS 1.3 and Post-Quantum Crypto Closer to Stable
The second beta of OpenSSL's next major feature line is out, and it quietly carries more of your encrypted internet traffic than most people ever think about. Released today, 4.1.0-beta2 pulls two long-awaited capabilities closer to production: native DTLS 1.3 support and a deeper integration of NIST post-quantum cryptography algorithms.
Almost every secure website you visit, every signed software package, and every VPN you connect rests on this one open-source library. Its two halves: libssl, which handles TLS, DTLS, and QUIC, and libcrypto, the general-purpose engine doing the actual work. Together they're baked into operating systems, web servers, routers, IoT firmware, and blockchain nodes.
It's the kind of software you notice only when it breaks. The Heartbleed memory leak of 2014, the CCS injection bypass that same year, and the predictable-key mess in Debian back in 2008 all rippled out across millions of systems.
OpenSSL takes its version numbers seriously, and there's history behind that caution. The project deliberately skipped a "2.0" to dodge a clash with an existing FIPS module number, later relicensed the code under Apache 2.0, and still treats each major bump as a genuine compatibility promise. (For the record, its TLS 1.3 development was bankrolled by Akamai.) That track record partly explains why the line spawned rivals, most notably LibreSSL out of OpenBSD after the 2014 mess, plus BoringSSL from Google and AWS-LC from Amazon.
Keep in mind that 4.1 is a "feature release," per the project's own description. That means it adds capability rather than merely patching holes.
4.1.0-beta1 landed on September 23, 2026. This newer beta went up on the project's public GitHub mirror, pushed by the automation account openssl-machine, with release commit f43c356. As of writing, roughly 343 commits have since landed on master, pointing to an active climb toward the stable release. The work between the two betas was no small feat: a GitHub comparison shows 115 commits across 250 files by 37 contributors.
Like any beta, this build is for testing, not production. The feature set here matches what beta1 announced, so the real question is what 4.1 actually brings.
The 4.1 feature set
The headline addition is DTLS 1.3 (RFC 9147). DTLS is the UDP cousin of TLS, built for anything that can't survive TCP's ordered, loss-recovery behavior: WebRTC media, real-time audio and video, internet telephony, gaming, and some IoT and VPN traffic. OpenSSL now speaks the current standard natively, mirroring the TLS 1.3 handshake while layering on retransmission timers, fragmentation handling, and replay detection.
That's arguably the feature most people have been waiting for. Smaller additions fill in around it.
There's now RFC 8701 GREASE support, the practice of injecting throwaway random values during the handshake so protocol designs don't shatter once a new extension gets standardized. Servers can now multiplex DTLS alongside TLS through the SSL listener API, juggling both connection types from one unified interface. IKEv2 KDF support adds key-derivation for IPsec VPN connections. And there's initial support for the Elbrus2000 (e2k) architecture, the first step toward the Russian-made CPU line. More of a curiosity than a necessity right now, but it does widen the hardware map.
Most of the remaining 4.1 work lands under performance, with architecture-specific speedups aimed at the new post-quantum algorithms. Optimized ML-DSA and ML-KEM operations arrive on ppc64le, s390x, and x86_64, including AVX-512-accelerated SHAKE and AES-CBC work. That's the background grunt work that quietly makes NIST's three finalized PQC algorithms, ML-KEM, ML-DSA, and SLH-DSA, more practical to deploy ahead of the broad quantum-safe transition.
One thing to flag for DTLS testers: issue #32878 on KeyUpdate handling, where outstanding post-handshake records get dropped from the retransmission buffer. A fix is already in the pipeline for a later release.
Breaking changes and where 4.1 sits
This is still a beta, but 4.1 does flag a few changes that could bite during an upgrade. The tsget time-stamping utility now needs the CPAN module Net::Curl::Easy, replacing the abandoned WWW::Curl::Easy. Install that first, or the tool stops working. Two Windows targets dropped out (Windows-on-Itanium and Windows CE), and the no-ecdsa and no-ecdh configure options vanished since they never actually disabled anything as advertised. Use no-ec if you want to skip elliptic-curve crypto.
Older Windows toolchains get a lifeline too, with new VC-WIN32-MSVC2013 and VC-WIN64A-MSVC2013 build targets added to keep them alive.
Then there's the versioning math, which matters if you're planning a migration. 4.1 is non-LTS with an end-of-life of November 2027, while the current stable 4.0 is only supported until May 2027. That's a narrow window, and it means teams wanting real stability should probably aim for 4.2. That LTS release lands in April 2027 and stays supported until April 2032. Starting with 5.0 in October 2027, OpenSSL will ship a major release every other year.
Head here to the OpenSSL releases page or the GitHub mirror for the source tarballs. The build ships as source only, so there are no binaries to download.
One note before you upgrade: 4.1.0-beta2 is a testing build. Don't point it at production until a stable release lands.
