OpenSSL 3.0 End of Life: 7 September 2026 — What Breaks and What to Do

OpenSSL 3.0 was released on 7 September 2021 and receives its last security fix on 7 September 2026 — five years to the day, which is the minimum the project's LTS policy promises. The final year, the one ending now, was security fixes only.

There are two dates here, not one, and the second is the one that catches regulated environments off guard.

What actually stops on 7 September 2026

The OpenSSL project stops publishing releases for the 3.0 line. There is no switch, no expiry check, no warning at runtime. A binary linking 3.0.22 on 8 September does exactly what it did on the 6th.

What ends is the patch supply. OpenSSL is the software that CVEs get written about — a vulnerability in the TLS stack after that date has no upstream 3.0 fix, and no amount of not-upgrading makes it not apply to you.

Before deciding whether this is your problem, work out where your OpenSSL came from, because it decides the answer:

• From your distribution — apt install openssl on Ubuntu 22.04, or the system packages on RHEL 9, both of which shipped 3.0 — and the distribution's security team keeps patching the version it shipped for its own support window, which outlasts the upstream date. You are covered, by them, not by the OpenSSL project.
• From anywhere else — a container base image, a build you compiled, a vendored copy inside a commercial application, a statically linked binary, a language runtime that bundles its own — and nobody is patching it after this date. This is the common case, and the harder one to audit, because vendored OpenSSL does not show up in a package list.

The second date: 21 September 2026

Two weeks after end of life, the CMVP moves the remaining FIPS 140-2 validations to its Historical List. That includes the OpenSSL FIPS Provider — the module that made OpenSSL 3.0 the version regulated deployments standardised on in the first place.

A validation on the Historical List does not stop working, and it does not retroactively invalidate anything already deployed. What it stops doing is satisfying a new procurement requirement. If you sell into government, healthcare, finance, or anywhere a contract names FIPS-validated cryptography, this is the date your compliance story changes — and it is not the date on the calendar everyone is looking at.

The two dates are why OpenSSL 3.0 is worth handling deliberately rather than folding into a general patch cycle. Most software's end of life is one event. This is two, aimed at two different audiences, a fortnight apart.

What breaks if you stay

Not TLS. Your connections keep negotiating, your certificates keep validating, your handshakes keep completing. The failures are institutional rather than technical, and they arrive on other people's schedules.

Scanners flag it by version, and there is no patch that clears the finding. Tenable's naming for this class is SEoL — Security End of Life. The 1.1.1 equivalent shipped as:

OpenSSL SEoL (1.1.1.x)

A 3.0.x sibling follows the same pattern once the date passes. The finding fires on the version string, not on any specific vulnerability, so there is nothing to remediate short of moving the library. It stays open in every report until you do.

Vendored copies surface in SBOM review. If you ship software to anyone who asks for a software bill of materials, an unsupported cryptographic library is the line item that gets circled. This is where statically linked OpenSSL stops being invisible — the SBOM lists it whether or not your package manager does.

Container images rot quietly. A base image pinned to a distribution that has itself moved on stops receiving OpenSSL updates while continuing to build and run perfectly. The image still pulls. It is simply frozen, CVEs included.

Language runtimes carry their own. Several bundle OpenSSL rather than linking the system copy, which means a runtime upgrade — not an OpenSSL upgrade — is what moves you. Check what your runtime reports, not what your distribution reports; they are frequently different numbers.

What the cloud providers and distributions do

Upstream's date is rarely the one that forces the issue. The organisation between you and OpenSSL runs its own clock:

Long-support distributions — Ubuntu 22.04 LTS and RHEL 9 both shipped 3.0 — patch it for their own windows, which extend past September 2026. This is a real support commitment, not a technicality, and it is why a large share of the installed base is genuinely unaffected on the day. It also has a hard edge: it covers the distribution's package, and nothing else on the machine.

Managed platforms deprecate on their own terms and usually give notice by email months ahead. As with any managed runtime, the provider's date is the one that will interrupt a deploy; the upstream date is the one that decides whether anyone is fixing bugs.

Commercial extended support exists for OpenSSL specifically, from the OpenSSL Corporation and from third parties, and it is a legitimate answer for a codebase that genuinely cannot move. It buys time to migrate without running unmaintained cryptography in production — which is the actual thing to avoid.

The upgrade path: 3.0 → 3.5 LTS

Target 3.5. It is the current LTS, supported until 8 April 2030, and the project now ships an LTS every two years in odd-numbered Aprils with at least five years of support each. That cadence is worth internalising: it makes the next decision date predictable rather than a surprise.

Do not target 3.4 or 3.6. Neither is LTS, and both expire in late 2026 — 3.4 on 22 October and 3.6 on 1 November. Upgrading to either buys you weeks and then puts you back here.

The good news, and it is genuinely good: this is not another 1.1.1. OpenSSL's release policy states that no API or ABI breaking changes are allowed in a minor or patch release, and 3.5 is a minor release within the same major version as 3.0. So for most software this is a rebuild and a relink, not a source port. The 1.1.1 → 3.0 migration that everyone remembers as painful crossed a major version and broke both API and ABI; this one does not.

What still needs doing:

1. Find every copy. The system package is the easy one. The work is in container images, vendored builds, statically linked vendor binaries, and runtimes that bundle their own. Anything that reports an OpenSSL version is a copy you own.
2. Rebuild and relink anything you compile yourself. Then run your test suite against TLS endpoints, not just unit tests — the interface is stable, but behaviour around defaults and deprecated algorithms is where surprises live.
3. Check your FIPS position separately if it applies. The library upgrade and the validation question are different problems with different deadlines.
4. Expect new defaults. 3.5 enables hybrid post-quantum key exchange for TLS 1.3 by default. That is a change in what your handshakes negotiate, and worth verifying against anything with strict middlebox inspection.

If you can't upgrade yet

Some things genuinely cannot move by September — a vendor binary you do not build, a certified configuration, an appliance.

Establish whether your distribution covers you. If the OpenSSL in question came from Ubuntu 22.04 or RHEL 9, you have a supported library for longer than the upstream date suggests, and the honest answer may be that you already have the time you need.

Consider commercial extended support for the copies your distribution does not cover. Paying for security fixes on an old cryptographic library is a better position than not receiving them.

Inventory before the date, not after. The hardest part of this migration is not the upgrade — it is discovering, in November, a statically linked OpenSSL inside a vendor binary nobody knew was there. Run the audit now, while the answer is still "we have time".

Write down the date you are deferring to. The most common failure here is not deciding to stay on 3.0. It is staying on 3.0 without anyone deciding to.

Sources

• OpenSSL release strategy — the LTS cadence and the API/ABI guarantee, quoted above
• FIPS 140-2 sunsets in September 2026 — the CMVP Historical List date
• Tenable plugin 182308 — the OpenSSL SEoL finding pattern
• endoflife.date: OpenSSL — the dates on this page, MIT licensed