OpenSSL 3.5 Beta Release Announcement
The OpenSSL Project is pleased to announce that OpenSSL 3.5 Beta1 pre-release is released and adding significant new functionality to the OpenSSL Library.
The OpenSSL Project is pleased to announce that OpenSSL 3.5 Beta1 pre-release is released and adding significant new functionality to the OpenSSL Library.
Thank you to everyone who registered and to those who went the extra mile to nominate candidates for the Technical Advisory Committees of the OpenSSL Corporation and OpenSSL Foundation.
The OpenSSL Corporation (primarily focused on commercial communities) and the OpenSSL Foundation (primarily focused on non-commercial communities) are pleased to announce the formation of the Technical Advisory Committees (TACs) to provide expert guidance and strategic direction for our technical initiatives. This marks a significant milestone, and we need dedicated individuals to help shape their future.
The OpenSSL Project is pleased to announce that OpenSSL 3.5 Alpha1 pre-release is released and adding significant new functionality to OpenSSL Library.
The OpenSSL Corporation is pleased to announce that OpenSSL version 3.1.2 has achieved FIPS 140-3 validation, signifying its compliance with the rigorous cryptographic module security requirements set forth by the National Institute of Standards and Technology (NIST). This accomplishment marks a significant milestone in reinforcing trusted, standards-based encryption for organizations operating in regulated environments, including government agencies, healthcare institutions, and financial services.
The OpenSSL Project is announcing the upcoming release of OpenSSL 3.5 Alpha, scheduled for March 11, 2025. As a result, the repository will be frozen before the release on March 6, 2025.
The included features can be found in the OpenSSL 3.5 Feature Go/No-Go Decision blog post.
We are pleased to announce that OpenSSL 3.5 will be the next long term stable (LTS) release. Per OpenSSL’s LTS policy, 3.5 will be supported until April 8, 2030.
The previous LTS (OpenSSL 3.0) will continue to be fully supported until September 7, 2025 and receive security fixes until September 7, 2026. Projects that currently depend on 3.0 are strongly encouraged to switch to OpenSSL 3.5 once it has been released.
In addition, the OpenSSL Corporation and Foundation have agreed to designate an LTS every two years. That means there will be an LTS release in April of 2027, another in 2029, and so on. As always, each LTS will be supported for 5 years with the final year’s support being security patches only. For more information, please see the OpenSSL Library Roadmap.
We’re introducing a streamlined process for deciding which new features make it into each OpenSSL Library release. This involves two layers of readiness checks—technical and business—to help ensure features are both technically sound and well-aligned with the broader needs of the communities. For OpenSSL 3.5, the OpenSSL Technical Committee (OTC) has advised on technical readiness, and the Business Advisory Committee has advised on business readiness.
The go/no-go decisions ensure we merge well-vetted features into the main codebase for OpenSSL 3.5, complementing OpenSSL Library’s existing review process.
The freeze date for OpenSSL 3.5 Alpha is rapidly approaching. If you have a feature on the planning page, please ensure that your associated PRs are posted, reviewed, and ready to be merged before the include/exclude decision date (Tuesday, February 11, 2025) and merged before the repository freeze date (Tuesday, February 25, 2025). Otherwise, the feature will be postponed until the next release.
If you have any questions or comments regarding the OpenSSL 3.5 release contact us at feedback@openssl.org.
The anticipated future arrival of cryptographically relevant quantum computers (CRQCs), that could undermine the algorithms that underlie the currently most widely used public key algorithms (ECDHE, ECDSA, DH and RSA), has led to the development and recent standardisation of new “post-quantum” (PQ) algorithms, that are believed to not be vulnerable to CRQC attack.
Two of the first algorithms standardized are ML-KEM (for key agreement) and ML-DSA (for digital signatures). These algorithms are standardized by NIST in FIPS 203 and FIPS 204. These define the algorithm parameters and how to correctly perform the necessary mathematical operations, but do not define such details as data formats for public and private keys. Those details were left to other standards organisations, such as the IETF.