OpenSSL LTS strategy alignment with future Node majors

[panva]

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

Project	Version	Milestone	Date
Node.js	27.x	Alpha begins	Oct 2026
Node.js	27.x	Initial Current release	Apr 2027
Node.js	27.x	Enters LTS	Oct 2027
Node.js	27.x	EOL	2030-04-30
OpenSSL	3.5	LTS supported until	2030-04-08
OpenSSL	4.1	non-LTS release	before 4.2
OpenSSL	4.2	LTS release	~Apr 2027
OpenSSL	4.2	Supported until	~Apr 2032

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:

• Node.js 27.x carries the intended next OpenSSL LTS for its full lifecycle.
• Avoids a major OpenSSL upgrade during the 27.x Current phase.
• Avoids shortening Node.js 27.x support.

Cons:

• Delays the first release under the new annual schedule.
• Reduces the stabilization window before October 2027 LTS.
• Depends on OpenSSL 4.2 release timing and readiness.

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:

• Preserves the Node.js 27.x April 2027 release target.
• Allows Node.js 27.x LTS to be covered by OpenSSL 4.2 through EOL.
• Gives some time to absorb OpenSSL 4.2 after its release.

Cons:

• Requires a major OpenSSL upgrade during the Current phase.
• Leaves less time to validate OpenSSL 4.2 before LTS.
• May create compatibility, build, test, or ecosystem risk close to LTS promotion.

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:

• Avoids an OpenSSL major-version upgrade in Node.js 27.x.
• Keeps Node.js 27.x on the already-established OpenSSL 3.5 LTS line.
• Lowest dependency-change risk for 27.x.

Cons:

• Current Node.js 27.x EOL is 2030-04-30, while OpenSSL 3.5 support ends 2030-04-08.
• Node.js 27.x support would need to be shortened by roughly one month.
• Creates an exception to the new 30-month LTS expectation.

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:

• Preserves the Node.js 27.x April 2027 release target.
• Avoids an OpenSSL major-version upgrade during Node.js 27.x Current.
• Allows Node.js 27.x LTS to be covered by OpenSSL 4.2 through EOL.
• Gives Node.js 27.x earlier exposure to OpenSSL 4.x before LTS.

Cons:

• Ships Node.js 27.0.0 with a non-LTS OpenSSL release. Still a supported one though. Not really a con.

References

• Node.js release schedule update: https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule
• Node.js release schedule data: https://github.com/nodejs/Release/blob/main/schedule.json
• OpenSSL release strategy: https://openssl-library.org/policies/releasestrat/
• OpenSSL roadmap: https://openssl-library.org/roadmap/index.html

[richardlau]

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.

[aduh95]

There 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

[panva]

• 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.

[panva]

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

Now promoted to its own Option 4.

[aduh95]

• 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.

[panva]

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.

[panva]

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, and privateKeyIdentifier.
  • Those options are exposed through tls.createSecureContext() and through APIs that create or consume TLS secure contexts, including tls.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)

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() and minDHSize-related behavior.

• Deprecated RFC 8422 elliptic curves are disabled by default.

  • This includes secp256k1.
  • TLS ecdhCurve configurations that include deprecated curves may now fail.

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_FAILURE
  • ERR_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 use TLS_server_method() instead.

• Some OpenSSL structs/APIs now require accessor functions and stricter const-correctness.

  • Node’s ncrypto compatibility work moved to accessors such as ASN1_STRING_get0_data() / ASN1_STRING_length() and adjusted X.509 extension handling.

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.

[richardlau]

In terms of breaking changes, IIRC OpenSSL engine support (which was deprecated) has been removed from OpenSSL 4.

[panva]

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

[richardlau]

Yeah, 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.