Library
OpenSSL
The OpenSSL 3.4 release line reaches end of support on 22 October 2026 and OpenSSL 3.6 on 1 November 2026; after each date that line receives no further fixes, including security fixes. The supported successors are OpenSSL 3.5 (LTS, until 2030-04-08) and OpenSSL 4.0 (until 2027-05-14).
departs 22 Oct 2026
Quick answers
- Is it true that OpenSSL 3.4 reaches end of life on 22 October 2026, and OpenSSL 3.6 on 1 November 2026 — upgrade to 3.5 LTS or 4.0?
- Yes. OpenSSL has officially announced it, effective 22 Oct 2026. If your applications, containers, or build images link against OpenSSL 3.4 or 3.6, those lines stop being supported within weeks: OpenSSL 3.4 on 22 October 2026 and OpenSSL 3.6 on 1 November 2026, per the OpenSSL project's own release strategy.
- When does it take effect?
- 22 Oct 2026. Verified against the vendor's own announcement.
- What should I use instead?
- Move to a supported line.
What this means for you
If your applications, containers, or build images link against OpenSSL 3.4 or 3.6, those lines stop being supported within weeks: OpenSSL 3.4 on 22 October 2026 and OpenSSL 3.6 on 1 November 2026, per the OpenSSL project's own release strategy. "No longer supported" for a crypto library means no further fixes of any kind — including security fixes for vulnerabilities discovered after the date — so any new OpenSSL CVE goes unpatched on that line. Because OpenSSL is almost always a transitive dependency (pulled in by your language runtime, your HTTP/TLS stack, or your base container image rather than named directly), the versions actually running in production are easy to lose track of — the risk is shipping a container or a host that silently carries an unsupported TLS library.
Where to go
Move to a supported line. OpenSSL 3.5 is the Long Term Support release, supported until 8 April 2030, and is the right target for most workloads that want stability; OpenSSL 4.0 is supported until 14 May 2027 for those tracking the current regular line. Audit where OpenSSL actually comes from in your stack: the version baked into your base container image (rebuild on a newer base to pull a supported OpenSSL), the version your language runtime bundles or links, and anything statically linking libcrypto/libssl. Note that OpenSSL 3.0, 1.1.1, and 1.0.2 are already out of support (paid extended support exists for security fixes on those), so a jump straight to 3.5 LTS avoids landing on another line with a near-term end date. ABI compatibility holds within a major version, so moving between 3.x lines generally does not require recompiling applications.
- OpenSSL 3.5 (LTS) — supported until 2030-04-08, the recommended long-term target
- OpenSSL 4.0 — supported until 2027-05-14, the current regular release line
The OpenSSL project runs a predictable release calendar — a new release every six months, with a Long Term Support release every two years — and two of its current lines reach end of support within weeks of each other. Per the project’s own Release Strategy:
- OpenSSL 3.4 — supported until 22 October 2026.
- OpenSSL 3.6 — supported until 1 November 2026.
After each date, that line receives no further fixes of any kind, including security fixes. For a cryptography library, that is the part that matters: a vulnerability found after the end-of-support date simply does not get patched on an unsupported line.
Why this one is easy to miss
OpenSSL is almost never a dependency you name directly. It arrives through your base container image, your language runtime, or whatever TLS/HTTP stack you link against. So the version actually running in production is easy to lose track of — and the failure mode here is quiet: a container or host that keeps working perfectly while carrying a TLS library that no longer receives security fixes.
Supported successors
Per the same page:
- OpenSSL 3.5 is the LTS release — supported until 8 April 2030. For most workloads that want stability, this is the target.
- OpenSSL 4.0 — supported until 14 May 2027 — the current regular line.
Note that OpenSSL 3.0, 1.1.1, and 1.0.2 are already out of support (paid extended support exists for security fixes on those lines), so jumping straight to 3.5 LTS avoids landing on another line with a near-term end date.
What to do
- Find where OpenSSL comes from in each service: the base image, the runtime bundle, and anything statically linking
libcrypto/libssl. - Rebuild on an updated base image (or bump the runtime) to pull a supported OpenSSL.
- Target 3.5 LTS unless you have a specific reason to track 4.0.
ABI compatibility holds within a major version, so moving between 3.x lines generally does not require recompiling applications — the work is mostly in rebuilding images and confirming what each layer links.
Entry changelog
- — last reviewed.
- — Entry created from the OpenSSL project's own Release Strategy page (server-rendered): "Version 3.4 will be supported until 2026-10-22", "Version 3.6 will be supported until 2026-11-01", "Version 3.5 will be supported until 2030-04-08 (LTS)", "Version 4.0 will be supported until 2027-05-14". sunsetDate set to 2026-10-22 (the soonest of the two imminent EOLs, OpenSSL 3.4); OpenSSL 3.6's 2026-11-01 EOL is covered in the body. No detect: fingerprint — OpenSSL is overwhelmingly a transitive/system library (bundled by the base image or language runtime), not a version-pinned dependency declared in a repository manifest, so there is no reliable primary-source code token to match without over-firing.
Put this countdown in your README
Building on OpenSSL? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/openssl-3-4-3-6-end-of-life)Spot an error or a changed date? Tell us and it’s corrected the same night.