Node.js refreshes its TLS chain: NSS 3.126 roots, OpenSSL 3.5.8, and STORE-loader private keys

Node.js shipped two releases a day apart: 24.21.0 “Krypton” (LTS) on 8 September 2026, followed by 26.8.2 (Current) on 9 September. Neither breaks anything, yet both refresh the TLS trust chain, and the LTS line picks up the ability to load private keys through OpenSSL’s STORE loaders. For a production fleet this is a security and cryptographic-hygiene update, not a release to admire from a distance.

#Two lines, two releases in one weekend

The branches follow their own schedules: 24.x remains the LTS line recommended for production, while 26.x is the Current line where new features land first. The table below sums up what each one carries.

The LTS line keeps Undici on 7.x to preserve compatibility, whereas Current tracks the 8.x series. OpenSSL, on the other hand, lands on 3.5.8 on both sides.

#A trust chain brought back up to date

The broadest change touches outbound TLS trust. Version 24.21.0 bundles Mozilla’s root certificate store in its NSS 3.126 revision, and OpenSSL moves to 3.5.8. In practice, a service that calls third-party APIs over HTTPS gets its root store resynchronised with the authorities the rest of the ecosystem considers valid: authorities added, authorities removed, constraints tightened. A runtime frozen on old roots eventually rejects a legitimate certificate, or trusts an authority Mozilla dropped long ago.

node -p "process.versions.openssl"   # 3.5.8
node -p "process.versions.undici"    # 7.29.1 en LTS 24.x, 8.10.2 en 26.x
node -e "console.log(require('tls').rootCertificates.length)"  # racines NSS embarquées

#Loading a private key without putting it on disk

The semver-minor highlight of 24.21.0 is support for private keys loaded through OpenSSL’s STORE loaders (contributed by Filip Skokan). Where a key previously had to exist as a PEM file readable by the process, OpenSSL 3 can expose a key through a provider: a PKCS#11 module backed by an HSM, a system store, a dedicated agent. The key then stays behind its provider, and application code only handles a reference to it.

A private key that never touches the filesystem is a key no volume leak can compromise.

The entry point is configured on the OpenSSL side, through the configuration file that activates the desired provider. Node.js then relies on that provider to resolve the key when it sets up the TLS context.

# openssl.cnf : activer un fournisseur adossé a un HSM
[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
activate = 1

[pkcs11_sect]
module = /usr/lib/ossl-modules/pkcs11.so
activate = 1

This switch is in no way mandatory: most deployments will keep reading a PEM file. It does, however, open a long-awaited door for teams under strict secret-retention requirements, who until now refused to see a production key sitting in clear text on an application disk.

#What the LTS line gains along the way

Version 24.21.0 backports several semver-minor additions already proven on the Current line. The Histogram objects in perf_hooks gain statistical hypothesis testing and a revised implementation, net.BlockList sees its performance improved, and util.MIMEType.parse() gets a variant that returns null instead of throwing on invalid input. Nothing spectacular, but that many fewer rough edges for code already in production.

#What to take away

Both releases are about maintenance rather than announcement: no new structuring API, but a resynchronised TLS chain and one more security lever for private keys. The right move is to schedule the 24.21.0 LTS upgrade across production servers, prioritising those that open outbound HTTPS connections to third parties. Running Node.js in production is best served by treating these minor versions as security links, on a par with an application patch.

Further reading: Node.js 24.21.0 & Node.js 26.8.2.