|
|
Log in / Subscribe / Register

OpenSSL 4.0.0 released

Version 4.0.0 of the OpenSSL cryptographic library has been released. This release includes support for a number of new cryptographic algorithms and has a number of incompatible changes as well; see the announcement for the details.


From:  'Matt Caswell' via openssl-project <openssl-project-AT-openssl.org>
To:  openssl-users <openssl-users-AT-openssl.org>, openssl-project <openssl-project-AT-openssl.org>
Subject:  Release Announcement for OpenSSL 4.0.0
Date:  Tue, 14 Apr 2026 14:19:19 +0100
Message-ID:  <CAODx15cHQz_xjDbBe16XFjjBrgaEb212tmMya6zrW=bhWhXCAg@mail.gmail.com>

The final release of OpenSSL 4.0.0 is now live. We would like to thank all
those who contributed to the OpenSSL 4.0.0 release, without whom the
OpenSSL Library would not be possible. OpenSSL 4.0 will be supported until
14th May 2027.

OpenSSL 4.0.0 is a feature release adding significant new functionality
to OpenSSL.

This release incorporates the following potentially significant or
incompatible
changes:

  * Removed extra leading '00:' when printing key data such as an RSA
modulus
    in hexadecimal format where the first (most significant) byte is >=
0x80.

  * Standardized the width of hexadecimal dumps to 24 bytes for signatures
    (to stay within the 80 characters limit) and 16 bytes for everything
else.

  * Lower bounds checks are now enforced when using `PKCS5_PBKDF2_HMAC` API
    with FIPS provider.

  * Added AKID verification checks when `X509_V_FLAG_X509_STRICT` is set.

  * Augmented CRL verification process with several additional checks.

  * `libcrypto` no longer cleans up globally allocated data via `atexit()`.

  * `BIO_snprintf()` now uses `snprintf()` provided by libc instead of
internal
    implementation.

  * `OPENSSL_cleanup()` now runs in a global destructor, or not at all
    by default.

  * `ASN1_STRING` has been made opaque.

  * Signatures of numerous API functions, including those that are related
    to X509 processing, are changed to include `const` qualifiers for
argument
    and return types, where suitable.

  * Deprecated `X509_cmp_time()`, `X509_cmp_current_time()`,
    and `X509_cmp_timeframe()` in favor of `X509_check_certificate_times()`.

  * Removed support for the SSLv2 Client Hello.

  * Removed support for SSLv3.  SSLv3 has been deprecated since 2015,
    and OpenSSL had it disabled by default since version 1.1.0 (2016).

  * Removed support for engines.  The `no-engine` build option
    and the `OPENSSL_NO_ENGINE` macro are always present.

  * Support of deprecated elliptic curves in TLS according to [RFC 8422] was
    disabled at compile-time by default. To enable it, use the
    `enable-tls-deprecated-ec` configuration option.

  * Support of explicit EC curves was disabled at compile-time by default.
    To enable it, use the `enable-ec_explicit_curves` configuration option.

  * Removed `c_rehash` script tool.  Use `openssl rehash` instead.

  * Removed the deprecated `msie-hack` option from the `openssl ca` command.

  * Removed `BIO_f_reliable()` implementation without replacement.
    It was broken since 3.0 release without any complaints.

  * Removed deprecated support for custom `EVP_CIPHER`, `EVP_MD`,
`EVP_PKEY`,
    and `EVP_PKEY_ASN1` methods.

  * Removed deprecated fixed SSL/TLS version method functions.

  * Removed deprecated functions `ERR_get_state()`, `ERR_remove_state()`
    and `ERR_remove_thread_state()`. The `ERR_STATE` object is now always
    opaque.

  * Dropped `darwin-i386{,-cc}` and `darwin-ppc{,64}{,-cc}` targets
    from Configurations.

This release adds the following new features:

  * Support for Encrypted Client Hello (ECH, [RFC 9849]).
    See `doc/designs/ech-api.md` for details.

  * Support for [RFC 8998], signature algorithm `sm2sig_sm3`, key exchange
    group `curveSM2`, and [tls-hybrid-sm2-mlkem] post-quantum group
    `curveSM2MLKEM768`.

  * cSHAKE function support as per [SP 800-185].

  * "ML-DSA-MU" digest algorithm support.

  * Support for SNMP KDF and SRTP KDF.

  * FIPS self tests can now be deferred and run as needed when installing
    the FIPS module with the `-defer_tests` option of the `openssl
fipsinstall`
    command.

  * Support for using either static or dynamic VC runtime linkage
    on Windows.

  * Support for negotiated FFDHE key exchange in TLS 1.2 in accordance
    with [RFC 7919].

-- 

Matt Caswell, Executive Director, OpenSSL Foundation
<http://openssl.foundation>
We need your support! Help us
<https://openssl.foundation/donate/ways-to-give> protect digital privacy…
everywhere.


to post comments

OpenSSL 4.0 is not an LTS

Posted Apr 14, 2026 15:42 UTC (Tue) by geofft (subscriber, #59789) [Link] (1 responses)

Note that 4.0 is not an LTS, and its support lifecycle (May 2027) is shorter than that of the latest LTS (3.5, April 2030). The next LTS is planned come out a year from now.

https://openssl-library.org/post/2025-02-20-openssl-3.5-lts/

OpenSSL 4.0 is not an LTS

Posted May 11, 2026 9:59 UTC (Mon) by sammythesnake (guest, #17693) [Link]

I figure it makes sense to let the .0 settle a bit before deciding on which point release makes a good LTS base...

Is anyone there?

Posted Apr 15, 2026 22:07 UTC (Wed) by izhaqblues (guest, #183273) [Link] (1 responses)

Thanks for the post! OpenSSL 3.5 LTS is gonna hit EOL in 2030, so before that I think it's pretty unlikely they'll flip the switch to OpenSSL 4. The enterprise distros will still have support from 2029 to 2032 anyway...
I really missed some solid details on the NIST post-quantum algorithms. I was also dying for more info on exactly which architectures and systems this version was actually tested on. I get it for amd64/x86 and all, but I really wanted to know how this whole key-switch is supposed to work on embedded systems or real-time stuff.
What bugs me the most is the total lack of any formal contact channel. Like, say you find a specific bug in the NIST ML-KEM (Kyber) implementation — how the hell do you even report it? What's the track record on implementations and bugs anyway? I'm not attacking the theoretical or math foundations at all, just the actual implementation. You can't really trust algorithms that haven't been battle-tested in real adversarial scenarios. I know nist.gov/pqc exists, but there's zero public, audited info on what actually went down there.
How are we supposed to just believe we have to make the switch? And how do we know there's no hybrid-computation telemetry sneaking around? I'm honestly blown away that simply questioning the implementation gets treated like some kind of dogma.

Is anyone there?

Posted Apr 16, 2026 12:40 UTC (Thu) by daroc (editor, #160859) [Link]

A cryptographer I follow, Soatok, recently published a blog post that links to some good resources on that topic. See the section "What about implementation risks?".


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds