Repository navigation
OpenSSL LTS strategy alignment with future Node majors #1869
Description
Activity
As I was reading the description, this was my first thought (before I got to it):
Alternatively, ship 27.0.0 with OpenSSL 4.1 (non-LTS) and upgrade to OpenSSL 4.2 LTS during Current thus avoid a major OpenSSL bump
I'm not keen on shortening Node.js 27's support.
Reacted by Michaël Zasso, Antoine du Hamel and Rafael GonzagaThere are other options, such as:
- ship 27.0.0 with OpenSSL 4.1, and move to 4.2 in a semver-minor (EDIT: didn't notice it was mentioned in Option 2 as alternative)
- maintain OpenSSL 3.5 ourselves for the 3 weeks of lack of overlap
- ship 27.0.0 with OpenSSL 4.1, and move to 4.2 in a semver-minor
I do note that as an option (of an option) in Option 2. And it is my preferred way forward.
Reacted by Marco IppolitoAlternatively, ship 27.0.0 with OpenSSL 4.1 (non-LTS) and upgrade to OpenSSL 4.2 LTS during Current thus avoid a major OpenSSL bump
Now promoted to its own Option 4.
- Ships Node.js 27.0.0 with a non-LTS OpenSSL release. Still a supported one though.
Is that actually a con? Why? I think the only reason we try to avoid that is because it forces us to switch to a different OpenSSL version during the release line lifetime, but it seems that'll be the case whatever option we pick.
Is that actually a con? Why? I think the only reason we try to avoid that is because it forces us to switch to a different OpenSSL version during the release lifetime, but it seems that'll be the case whatever option we pick.
Updated.
Based on the work I did in allowing OpenSSL 4.x to be used here's the currently known set of breaking changes:
Engines
4.0 removed support for engines. The no-engine build option and the OPENSSL_NO_ENGINE macro are always present.
- This affects
crypto.setEngine().- This affects the engine-backed TLS options
clientCertEngine,privateKeyEngine, andprivateKeyIdentifier. - Those options are exposed through
tls.createSecureContext()and through APIs that create or consume TLS secure contexts, includingtls.createServer(),tls.connect(),https.createServer(), and HTTPS client APIs. - Calls that rely on engine support fail with
ERR_CRYPTO_CUSTOM_ENGINE_NOT_SUPPORTED. - The related
crypto.constants.ENGINE_METHOD_*constants are only exposed when OpenSSL engine support is available. - Those are all deprecated with no replacement (DEP0183)
- This affects the engine-backed TLS options
TLS behavior changes
-
OpenSSL 4.0 implements RFC 7919 FFDHE negotiation for TLS 1.2.
- Server-supplied DHE params may be ignored in favor of FFDHE-2048.
- This can change the negotiated ephemeral key from ECDHE to DHE, or change the reported DHE size.
- This affects
tlsSocket.getEphemeralKeyInfo()andminDHSize-related behavior.
-
Deprecated RFC 8422 elliptic curves are disabled by default.
- This includes
secp256k1. - TLS
ecdhCurveconfigurations that include deprecated curves may now fail.
- This includes
Error surface changes
-
Several TLS failure paths now report:
ERR_SSL_TLS_ALERT_HANDSHAKE_FAILURE
instead of older OpenSSL-specific spellings such as:
ERR_SSL_SSL/TLS_ALERT_HANDSHAKE_FAILUREERR_SSL_SSLV3_ALERT_HANDSHAKE_FAILURE
Affected cases include missing client certificates, empty SNI contexts, PSK identity failures, no shared ciphers, and no shared signature algorithms.
-
Some
crypto.diffieHellman()key-type mismatch / unsupported-key cases may report:ERR_OSSL_EVP_INTERNAL_ERROR
instead of:
ERR_OSSL_EVP_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE
This appears to vary by OpenSSL 4.0 build/platform.
Native / build compatibility changes
-
OpenSSL version-specific TLS methods were removed in OpenSSL 4.0.
- Code using APIs such as
TLSv1_2_server_method()must useTLS_server_method()instead.
- Code using APIs such as
-
Some OpenSSL structs/APIs now require accessor functions and stricter const-correctness.
- Node’s
ncryptocompatibility work moved to accessors such asASN1_STRING_get0_data()/ASN1_STRING_length()and adjusted X.509 extension handling.
- Node’s
This list may widen with the release of 4.1 but I expect not dramatically so.
I'd say we ship 27.0.0 with 4.1 (due in October 2026) and then update to 4.2 LTS (due in April 2027 alongside of 27.0.0) before 27's LTS transition in October 2027.
As far as tsc-agenda goes I'll present this next week as an FYI and then we can drop it from the agenda.
Reacted by Richard Lau- This affects
In terms of breaking changes, IIRC OpenSSL engine support (which was deprecated) has been removed from OpenSSL 4.
In terms of breaking changes, IIRC OpenSSL engine support (which was deprecated) has been removed from OpenSSL 4.
Yeah, which we're not testing for in any capacity hence my commit probe omitted it. Added now. DEP0183 should probably be moved forward to EOL. With no provider-based replacement as those are incompatible concepts.
DEP0183 is documentation-only so we'll at least runtime-deprecate it for 27
Reacted by Richard LauYeah, which we're not testing for in any capacity hence my commit probe omitted it.
No worries. I would not be surprised to find a few extra things when we try to vendor OpenSSL 4.x into Node.js based on experience when we updated from 3.0 to 3.5. We do skip over some tests when dynamically linking against OpenSSL.
Reacted by Filip SkokanMentioned in the release WG today. No voiced objections to Option 4.
Reacted by Filip Skokan and Antoine du Hamel- added a commit that references this issue
on Jul 3, 2026
Summary
Node.js 27.x and OpenSSL 4.2 LTS are both scheduled for April 2027. Because the releases land within weeks of each other, we need to decide how Node.js 27.x should handle OpenSSL before it enters LTS in October 2027.
The decision affects whether Node.js 27.x ships with OpenSSL 3.5 LTS, moves to OpenSSL 4.2 LTS before LTS promotion, ships first with a non-LTS OpenSSL 4.x release and updates to 4.2, or adjusts its release/support dates.
Note
Given the schedules aligning on April every 2nd year is a topic for us to solve every two years, hence opening this to set a pattern.
Refs: OpenSSL Release Strategy updated as of 07 May 2026 and its roadmap.
Relevant dates
Option 1: Postpone Node.js 27.0.0 for OpenSSL 4.2
Note
Initial release delays are not unheard of for us.
Delay the initial Node.js 27.x Current release long enough to include OpenSSL 4.2 LTS from the start.
Pros:
Cons:
Option 2: Release Node.js 27.0.0 with OpenSSL 3.5, then upgrade to 4.2 before LTS
Note
We've done this during 24.x: it was released initially with 3.0 and upgraded to 3.5 before LTS. That was not an OpenSSL major-version upgrade.
Ship Node.js 27.0.0 on schedule with OpenSSL 3.5 LTS, then update to OpenSSL 4.2 LTS during Current before October 2027 LTS promotion.
This is different from 24.x because it would move between OpenSSL major versions. We already have 4.0.0 compatibility, but it is not without minor breakage and observable behavior changes.
Pros:
Cons:
Option 3: Keep Node.js 27.x on OpenSSL 3.5 and shorten Node.js 27.x support
Note
We've shortened LTS for Node.js 16.x by ~7 months to align with EOL of OpenSSL 1.1.1. Node.js 8.x was also shortened by ~3 months to align with EOL of OpenSSL 1.0.2.
Keep Node.js 27.x on OpenSSL 3.5 LTS, but end Node.js 27.x support no later than OpenSSL 3.5's support end date. This would lose ~1 month worth of LTS.
Pros:
Cons:
Option 4: Release Node.js 27.0.0 with OpenSSL 4.1, then upgrade to 4.2 before LTS
Ship Node.js 27.0.0 with OpenSSL 4.1, a non-LTS OpenSSL 4.x release, then update to OpenSSL 4.2 LTS during Current before October 2027 LTS promotion.
This avoids moving from OpenSSL 3.x to 4.x during the Node.js 27.x Current phase. The remaining update before LTS would still need validation, but it would be within the same OpenSSL major version.
Pros:
Cons:
Ships Node.js 27.0.0 with a non-LTS OpenSSL release. Still a supported one though.Not really a con.References