OpenSSL 3.0 EOL is two weeks out. If you pinned it, that's your problem now.

OpenSSL 3.0 was released September 7, 2021. The LTS policy promises five years. Five years from September 7, 2021, is September 7, 2026. That is two weeks from today. No more security patches after that date. No backports, no advisories, no quiet fixes for the CVEs that will absolutely keep arriving.

If your production systems are pinned to OpenSSL 3.0, directly or through a distribution package that hasn’t moved, you have two weeks to fix that or accept the consequences.

What the LTS policy actually means

OpenSSL’s LTS releases get five years of full security support from the project. Non-LTS releases get considerably less: about a year and a half. OpenSSL 3.0 was the first LTS in the 3.x line, which is why it’s been sitting on servers since 2021 while 3.1, 3.2, 3.3, and 3.4 have all come and gone in its shadow.

After EOL, the OpenSSL Project will not publish security advisories for 3.0 flaws. They will not backport fixes. If a researcher drops a memory-corruption bug in a 3.0 code path next October, the official answer is “upgrade.” That’s it. Your distro’s security team might backport something if they’re still shipping 3.0, but that depends entirely on whether your distro considers 3.0 supported at that point, and most of them don’t.

The current LTS target in the 3.x line is 3.4, released in November 2024. Distributions that had already pulled 3.4 into their package repos have been on it for months. If yours hasn’t, check. The 3.4 → 3.5 upgrade path when it arrives will be straightforward; getting from 3.0 to current is the hard one because of the providers architecture change.

The providers thing

OpenSSL 3.0 introduced the “providers” model. Instead of algorithms being compiled directly into libssl, they’re loaded as modular providers: the default provider handles standard algorithms, the legacy provider handles older ones (DES, RC4, Blowfish, MD2, the embarrassing ones), and the FIPS provider wraps the validated module.

The API surface stayed largely compatible for most use cases. But the internal architecture changed enough that software assuming specific engine interfaces from OpenSSL 1.1.x had to be updated, and some of it was updated to assume 3.0 internals that have since been deprecated or changed in 3.2+.

In practice: if your code compiles and links against OpenSSL 3.0 without warnings, it will almost certainly compile against 3.4. If you’re calling ENGINE_* APIs, those are gone: they were deprecated in 3.0 and you’ve had five years to fix that. If you ignored it, the bill is due.

Run this against your binaries to see what they’re linking against:

ldd /path/to/binary | grep ssl
objdump -p /path/to/binary | grep NEEDED | grep ssl

Or more usefully, for finding everything on a system that links libssl:

find /usr/lib /usr/local/lib -name 'libssl.so.*' -exec ls -la {} \;
ldconfig -p | grep libssl

Then cross-reference which packages own binaries that depend on the version you’re about to stop getting patches for.

The FIPS situation is worse

If you run in a FIPS 140-2 validated environment (government, defense, healthcare, financial systems with compliance requirements), the situation is uglier. The OpenSSL FIPS module is validated against specific OpenSSL versions. The 3.0 FIPS module has its own certificate number. The 3.4 FIPS module is a different validation.

Switching FIPS module versions requires documentation, validation that your new module covers the algorithms your compliance requirements specify, and in some environments, formal approval from your compliance officer before you can deploy the change. Two weeks is not enough time to do that process correctly if you haven’t started.

If you’re in a FIPS environment and still on OpenSSL 3.0, you probably already know this, and you either have a plan or you’re about to have a very specific kind of meeting. I can’t help you with the meeting. I can tell you that “we knew two weeks in advance” is not a great opening.

Distribution coverage

Most major distributions have already moved:

Ubuntu 24.04 LTS shipped OpenSSL 3.3. Debian 13 Trixie ships 3.4. Alpine 3.20+ uses LibreSSL (the BSDs made the right call here years ago) and the musl-based ecosystem followed. RHEL and CentOS Stream are on 3.2.x in their current releases with backport SLAs through their own support windows.

The distribution that bites people is Ubuntu 22.04 LTS (Jammy), which shipped with OpenSSL 3.0 and maintains it as a core package. Ubuntu’s security team has been backporting fixes to their 3.0 package, but Ubuntu 22.04 itself hits EOL in April 2027. Their backport coverage for OpenSSL 3.0 continues through their own Ubuntu support window, not OpenSSL project’s.

The scenario to audit for: containerized workloads that build FROM ubuntu:22.04 or equivalent and install libssl-dev or openssl from that image’s package repo. Those get Ubuntu’s backports, not upstream patches. That’s fine until Ubuntu’s backport team doesn’t catch something. Whether you trust that gap depends on your risk tolerance, not mine.

What to actually do

If you’re on a distribution that ships 3.4+: nothing to do. You’re already there.

If you’re on Ubuntu 22.04 with containers: update your base images to 24.04. FROM ubuntu:24.04 in your Dockerfiles and test the build. Most applications see no behavioral difference. Applications using deprecated ENGINE or low-level API paths will fail to compile, which is the correct behavior: those paths are gone and they should have been rewritten before now.

If you’re managing bare-metal or VM systems pinned to OpenSSL 3.0 through a distro choice: the question is whether your distro is also EOL or still providing backports. Check your distro’s security announcement list. If you’re on something that stopped shipping backports, your actual problem is the distro upgrade, not just the library.

If you’re statically linking OpenSSL (common in Go binaries using cgo, some C applications, embedded systems), you have a static library that’s going stale regardless of what packages are installed. strings /path/to/binary | grep 'OpenSSL' will show you the compiled-in version string. Find those binaries and rebuild them against current OpenSSL.

The project gave five years of notice. That’s longer than most enterprise software cycles. “We didn’t have time” is a planning failure, not a library failure.

LibreSSL, the OpenBSD fork, handles this differently: they ship it with the OS and keep it current as part of the base system. There are no separate LTS cycles because there’s no separate library to track. I am not going to make this point more than once, but I’m also not going to pretend the contrast isn’t instructive.

See also: OpenSSH 10 dropping legacy algorithms for the same pattern in a different project (old crypto support ending on a schedule that was announced years in advance) and certificate lifetimes are collapsing for the broader TLS credential rotation context that makes staying on patched TLS libraries non-optional.