OpenSSL 3.0: What's New, Release History & EOL Status

How does the new provider architecture affect existing OpenSSL applications?

In OpenSSL 3.0 the provider model replaces the old ENGINE API, so cryptographic operations are fetched from named providers at runtime.

Key points for production:

• Default providers are default (general purpose) and legacy (deprecated algorithms).
• Applications can request a specific provider via OSSL_LIB_CTX or property strings, e.g. EVP_PKEY_new_from_name(ctx, "RSA", "provider=default").
• If a key resides in a provider that does not expose the requested operation, OpenSSL will fall back to a provider that does, provided the property query permits it.
• Code that directly called low-level RSA_* or DSA_* functions must migrate to the EVP API or explicitly load the legacy provider.

# List available providers
openssl list -providers

# Load the legacy provider in a program
OSSL_LIB_CTX *ctx = OSSL_LIB_CTX_new();
OSSL_PROVIDER_load(ctx, "legacy");

What are the most critical security fixes introduced in the 3.0 series?

OpenSSL 3.0 includes a steady stream of CVE-addressed patches that close use-after-free, null-pointer, and buffer-overflow bugs across the stack.

Highlights that matter to operators:

• RSA KEM encapsulation failure handling (CVE-2026-31790) - prevents malformed ciphertext from causing silent failures.
• Multiple NULL-pointer dereferences in CMS and PKCS#12 parsing (CVE-2026-28388-28390) - eliminates crashes when processing malformed messages.
• Heap buffer overflow in hex conversion (CVE-2026-31789) - safeguards logging and debugging utilities.
• Timing side-channel mitigations for ECDSA signatures (CVE-2024-13176) and RSA decryption (CVE-2022-4304) - improves resistance to remote timing attacks.
• Session memory growth bug in TLS 1.3 (CVE-2024-2511) - prevents unbounded RAM consumption under heavy load.

In practice, most of these fixes are back-ported automatically when you upgrade to the latest 3.0.x release, but you should verify that your deployment is running at least 3.0.20 to cover the newest mitigations.

Which legacy algorithms and APIs have been moved or deprecated in OpenSSL 3.0?

OpenSSL 3.0 moves all legacy ciphers, digests, and key-type functions into the legacy provider and marks the low-level APIs as deprecated.

Key changes you need to audit:

• Block ciphers such as DES, RC4, RC2, IDEA, and SEED are no longer available in the default provider; they require explicit loading of legacy.
• Digest algorithms MD2, MD4, MD5, MDC2, RIPEMD-160, SHA-1, SHA-224/256/384/512 (in low-level form) are deprecated; use the EVP digest API instead.
• Structures RSA, DSA, DH, EC_KEY and their *_METHOD counterparts are deprecated - migrate to EVP_PKEY and provider-based operations.
• The ENGINE subsystem and related functions (ENGINE_by_id, ENGINE_load_private_key, etc.) have been removed.
• ERR_load_* helpers are deprecated; use the new error-raising macros.

Watch out for configuration files or scripts that still reference the old names; they will fail unless the legacy provider is loaded.

How have TLS 1.3 and related session handling been improved?

OpenSSL 3.0 introduces several performance and stability enhancements for TLS 1.3.

• Session cache growth is now bounded, fixing unbounded memory usage (CVE-2024-2511).
• Pluggable TLS 1.3 groups allow applications to select post-quantum or custom groups via provider properties.
• Improved handling of large DH parameters reduces CPU spikes during handshake.
• Kernel TLS (KTLS) support is now part of the default provider, enabling zero-copy encryption on supported kernels.

In practice, enabling KTLS can reduce CPU overhead on high-throughput servers; configure it with SSL_set_options(ssl, SSL_OP_ENABLE_KTLS) after creating the context.