Blog

The OpenSSL Project is pleased to announce that OpenSSL 4.0 Beta1 pre-release is available, adding significant functionality to the OpenSSL Library.

The expiration date of the OpenSSL release signing key with fingerprint BA5473A2B0587B07FB27CF2D216094DFD0CB81EF has been extended from 08 Apr 2026 to 14 Jun 2026.

Only the key expiration date has changed. The signing key itself remains the same.

The updated public key is available at: https://keys.openpgp.org/search?q=BA5473A2B0587B07FB27CF2D216094DFD0CB81EF

Previous posts about the upcoming OpenSSL 4.0 release:

1. removing ENGINE code
2. removing deprecated functions for creating or modifying custom METHODS
3. no longer registering a function via atexit function

Summary

The OpenSSL Library now supports Encrypted Client Hello (ECH) specified in RFC 9849, which was published this month. Applications that implement this standard will be able to encrypt sensitive information that is currently transmitted in plaintext in the TLS 1.3 handshake. In particular, ECH can protect the client’s target server name from being revealed to third parties.

Previous posts about features removed from OpenSSL 4.0:

1. ENGINE code
2. deprecated functions for creating or modifying custom METHODS

Summary

The OPENSSL_cleanup() function is no longer registered to be called upon the termination of the process. This means the OpenSSL Library does not automatically free resources so the operating system reclaims them when an application exits.

For most users, this will have no impact since the memory is freed one way or the other.

The OpenSSL Project is announcing the upcoming release of OpenSSL 4.0 Alpha, scheduled for March 10, 2026. As a result, the repository will be frozen before the release on February 24, 2026.

Following on from the removal of ENGINE code, deprecated functions for creating or modifying custom METHODS will be removed from OpenSSL 4.0.

Summary

For a complete list of deprecated functions removed in OpenSSL 4.0, please see the ossl-removed-api documentation. They are divided into the following pull requests:

• Custom ciphers methods (EVP_CIPHER_meth_*) were removed in PR #29299.
• Custom message digest methods (EVP_MD_meth_*) were removed in PR #29366.
• Custom private key methods (EVP_PKEY_meth_*) were removed in PR #29384.
• Custom private key Abstract Syntax Notation One methods (EVP_PKEY_asn1_*) were removed in PR #29405. (These functions were deprecated in OpenSSL 3.6.)

Instead of using these methods, developers are encouraged to use the provider framework.

Release Announcement for OpenSSL Library 3.6.1, 3.5 5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn

The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.

OpenSSL 4.0, to be released in April 2026, is the first major release since 3.0 which replaced the ENGINE interface with Providers. Removing ENGINEs is a primary goal of this major release and this post describes the change agreed to by both the OpenSSL Corporation and OpenSSL Foundation.

Summary

All symbols defined in openssl/engine.h have been removed from the shared library in OpenSSL 4.0. Applications that use the ENGINE API will fail to compile using the default build settings. This behavior matches what happens in previous versions when building OpenSSL with the no-engine configuration option with current versions. Up-to-date applications should not include openssl/engine.h at all.

The voting from the Foundation BAC has been extended through December 21. If you want to participate in the future of the OpenSSL Foundation, please join the communities site and vote for your representative.

The currently running elections are:

• Academics
• Individuals
• Distributions
• Large Business
• Small Business

For details about how the election works, please consult the Foundation Election Guide.

The OpenSSL Library would like to modernise and streamline development processes, especially to ensure effective code review and make the project easier for contributors to contribute to.

As part of this effort, we will be making some changes to our coding style guidelines and adopting clang-format using the WebKit C coding style as enforced by clang-format. We will transition to using clang-format to check pre-submissions and ensure code follows the format portions of the style guide before PRs are reviewed.