- [OpenSSL 4.1](#openssl-41)
OpenSSL 4.1
-----------

### Changes between 4.0 and 4.1.0 [23 Oct 2026]
   *Shane Lontis and Paul Dale*

   Fixed TLS 1.3 clients to reject a `psk_use_session` callback PSK whose master
   key is empty, with `SSL_R_BAD_PSK`, instead of failing later in binder
   computation.

   *Viktor Dukhovni*
   *Frederik Wedel-Heinen and Ryan Hooper*
   *William McCormack*
   *Adriano Sela Aviles*
   *Ryan Hooper*
   *Ryan Hooper*
   *Nikolas Gauder*

   The point conversion form (compressed, uncompressed, or hybrid)
   is now a single value on the `EC_GROUP` and round-trips
   unchanged through import and export of `EC_KEY` objects.

   Freshly generated keys have their public point encoded
   in uncompressed form.  A `point-format` supplied at key generation
   time via `OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT`
   is validated (an invalid value is rejected) but otherwise ignored
   on the generated key.  EC parameter generation continues
   to honour the requested form on the group's generator;  imported
   keys keep their form.

   The `ec_point_formats` extension no longer affects TLS 1.2
   X.509 certificate selection or acceptance.  OpenSSL now
   accepts an EC certificate in any point form it can decode,
   and sends any EC certificate it has regardless of point form.
   TLS 1.3 disregards the extension entirely.

   The [RFC 4492][RFC 4492 Section 5.1.2]/[8422 section 5.1.2][RFC 8422 Section
   5.1.2]
   requirement that the peer's point-format list contain "uncompressed" is now
   enforced on both sides (previously client-only), and only when an ECC TLS 1.2
   ciphersuite is negotiated—a missing "uncompressed" is ignored under TLS 1.3
   or with a non-ECC cipher.
   <!-- -->

   *Viktor Dukhovni*
   *Daniel Kubec*
   *Dmitry Belyavskiy*

   If the `CMS_VERIFY_PARTIAL` flag is set, the `CMS_verify()` call
   is successful if at least one of the individual signatures can be verified
   (as opposed to all of them), which may be useful to gracefully handle various
   situations, like missing CAs, expired certificates, or unsupported
   algorithms;  applications can call `CMS_get0_signers()` to check if the set
   of valid signatures satisfies its policy, or use
   `CMS_SignerInfo_get_verification_result()`
   and `CMS_SignerInfo_get0_signer_cert()` functions to access the detailed
   verification results.
   <!-- -->

   *Jan Lübbe*

   This work was sponsored by Siemens AG.
   <!-- -->

   *David von Oheimb*
   *Paul Louvel*
   *Evy Garden*
   *Jakub Zelenka*
   *John Claus, Viktor Dukhovni, and David von Oheimb*

   When a provider requests seeding material before the primary DRBG
   has been created, the request falls back to the operating system entropy
   sources, because the seed source only comes into existence as a side
   effect of creating the primary DRBG.  Whether a configured seed source
   is used therefore depends on operation order.  With `seed_strict` enabled,
   the seed source is instead instantiated on demand and an error is reported
   if it cannot be used.  The option is off by default with two exceptions:
   the `JITTER` seed source seeds strictly unless the option disables it,
   and `enable-fips-jitter` builds always seed strictly.  Additionally,
   the property query used to fetch the default seed source can now be set
   at build time with `-DOPENSSL_DEFAULT_SEED_PROPQ`.
   <!-- -->

   *Jakub Zelenka*
   *Helen Zhang*
   *Neil Horman*
   *Igor Ustinov*
   *Leon Timmermans*
   *Bob Beck*

   The new setter functions do not append a terminating NUL byte to the newly
   allocated strings, contrary to historic `ASN1_STRING_set()`'s behaviour,
   so `ASN1_STRING_get0_data()` may return data not followed
   by an out-of-`ASN1_STRING_get_length()` bounds NUL byte (whose presence
   has never been guaranteed there by API contract) in more cases
   than it used to before.  A future release will switch to the usage
   of the new APIs internally.

   When OpenSSL is built with `AddressSanitizer` or `MemorySanitizer` support,
   or is run under Valgrind having been built where the Valgrind headers
   are installed, the added NUL byte is marked inaccessible, so treating
   the result of `ASN1_STRING_get0_data()` as a C string (`strlen()`, `%s`,
   `strdup()` and the like) is reported as an error.  All such uses
   must be changed to honour `ASN1_STRING_get_length()`. The Valgrind
   check may be disabled by building with `-DOPENSSL_NO_VALGRIND_CHECK`.
   <!-- -->
   <!-- -->
   <!-- -->

   *Bob Beck*
   *Todd Short*
   *Tim Perry*
   *Dimitri John Ledkov*
   *Dr Paul Dale*
   *Craig Lorentzen*
   *Daniel Kubec*
   *Tong Li*
   *Bob Beck*
   *Gleb Popov*

   When building with compilers that support GCS (Clang 18+, GCC 15+),
   assembly modules are marked as compatible when branch protection
   is enabled (e.g. `-mbranch-protection=standard`).  No functional changes
   to the assembly implementations are required, but compliance ensures
   correct operation with shadow stack enforcement.
   <!-- -->

   *Guillaume Gardet and Gowtham Suresh Kumar*
   *Danny Tsen*
   *Marcel Cornu and Tomasz Kantecki*
   *Marcel Cornu and Tomasz Kantecki*
   *Madan Mohan Manokar*
   *Bob Beck*
   *Enji Cooper*
   *Jakub Zelenka*
   *Jakub Zelenka*
   *Bob Beck*
   *Daniel Kubec and Viktor Dukhovni*
   *Mounir IDRASSI*
   *Mounir IDRASSI*
   *Viktor Dukhovni*
   *Daniel Kubec*
   *Viktor Dukhovni*
   *Viktor Dukhovni*
   *Mounir IDRASSI*
   *Adam Tabak*
   *John Claus*
   *Jakub Zelenka*
   *Milan Brož*
   *Paul Grubbs*
   *Bob Beck*
   *Shreenidhi Shedi*
   *Jakub Zelenka*
   *Bob Beck*
   *Bob Beck*
   *Shane Lontis*
   *Bob Beck*
   *Norbert Pócs*
   *Bob Beck*
   *Bob Beck*
   *Bob Beck*
   *Tomáš Mráz*
   Issue summary: The OpenSSL QUIC server, when configured to not perform
   This work was sponsored by Siemens AG.
   *David von Oheimb*

   where the (non-default) flag OCSP_NOCHECKS is used to return a positive
           NCONF_get_section, NCONF_get_string, NCONF_get_number
[RFC 4492 Section 5.1.2]:
https://datatracker.ietf.org/doc/html/rfc4492#section-5.1.2
[RFC 5280]: https://datatracker.ietf.org/doc/html/rfc5280
[RFC 5280 Section 6.3.3]:
https://datatracker.ietf.org/doc/html/rfc5280#section-6.3.3
[RFC 5652]: https://datatracker.ietf.org/doc/html/rfc5652
[RFC 7685]: https://datatracker.ietf.org/doc/html/rfc7685
[RFC 8422 Section 5.1.2]:
https://datatracker.ietf.org/doc/html/rfc8422#section-5.1.2
[RFC 8701]: https://datatracker.ietf.org/doc/html/rfc8701
[RFC 9147]: https://datatracker.ietf.org/doc/html/rfc9147
[RFC 9149]: https://datatracker.ietf.org/doc/html/rfc9149
[RFC 9846]: https://datatracker.ietf.org/doc/html/rfc9846
[RFC 9846 Section 4.3.10]:
https://datatracker.ietf.org/doc/html/rfc9846#section-4.3.10
[SECG SEC 1 Section 2.3.4]: https://www.secg.org/sec1-v2.pdf#subsubsection.2.3.4
[TCG Credential Profiles specification Version 1.2, Section 3.2.7]:
https://trustedcomputinggroup.org/wp-
content/uploads/Credential_Profiles_V1.2_Level2_Revision8.pdf#page=35