Node.js hat im Abstand eines Tages zwei Versionen veröffentlicht: 24.21.0 „Krypton“ (LTS) am 8. September 2026 und 26.8.2 (Current) am 9. September. Keine der beiden bricht etwas, doch beide frischen die TLS-Vertrauenskette auf, und die LTS-Linie erhält das Laden privater Schlüssel über die STORE-Loader von OpenSSL. Für einen Produktionsbestand ist das ein Sicherheits- und Krypto-Hygiene-Update, keine Version zum Betrachten aus der Ferne.
Zwei Linien, zwei Veröffentlichungen an einem Wochenende
Die Zweige folgen ihrem eigenen Zeitplan: 24.x bleibt die für die Produktion empfohlene LTS-Linie, 26.x ist die Current-Linie, in der Neuerungen zuerst landen. Die Tabelle fasst zusammen, was jede Linie mitbringt.
| Version | Linie | Datum | OpenSSL | Undici | Wurzeln |
|---|---|---|---|---|---|
| 24.21.0 „Krypton“ | LTS | 8. Sep. 2026 | 3.5.8 | 7.29.1 | NSS 3.126 |
| 26.8.2 | Current | 9. Sep. 2026 | 3.5.8 | 8.10.2 | aus 26.8.x |
Die LTS-Linie hält Undici in der 7.x-Reihe, um die Kompatibilität zu wahren, während Current der 8.x-Reihe folgt. OpenSSL hingegen landet auf beiden Seiten bei 3.5.8.
Eine wieder aktualisierte Vertrauenskette
Die breiteste Änderung betrifft das ausgehende TLS-Vertrauen. Version 24.21.0 bringt Mozillas Stammzertifikatsspeicher in der Fassung NSS 3.126 mit, und OpenSSL wechselt auf 3.5.8. Praktisch resynchronisiert ein Dienst, der Drittanbieter-APIs über HTTPS aufruft, seinen Wurzelspeicher mit den Zertifizierungsstellen, die der Rest des Ökosystems für gültig hält: hinzugefügte Stellen, entfernte Stellen, verschärfte Einschränkungen. Eine auf alten Wurzeln eingefrorene Laufzeitumgebung weist irgendwann ein legitimes Zertifikat zurück oder vertraut einer Stelle, die Mozilla längst gestrichen hat.
Auf einer LTS-Linie ist die Versuchung groß, kleinere Versionssprünge aufzuschieben. Stammzertifikate sind die Ausnahme: Lässt man sie altern, häuft sich Schuld an, die eines Tages in schwer zu diagnostizierenden UNABLE_TO_VERIFY_LEAF_SIGNATURE-Fehlern beglichen wird. Die mitgelieferten Versionen zu prüfen, dauert Sekunden.
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éesEinen privaten Schlüssel laden, ohne ihn auf die Platte zu legen
Das als semver-minor markierte Highlight von 24.21.0 ist die Unterstützung privater Schlüssel, die über die STORE-Loader von OpenSSL geladen werden (Beitrag von Filip Skokan). Wo ein Schlüssel bislang als vom Prozess lesbare PEM-Datei vorliegen musste, kann OpenSSL 3 einen Schlüssel über einen Provider bereitstellen: ein PKCS#11-Modul hinter einem HSM, einen Systemspeicher, einen dedizierten Agenten. Der Schlüssel bleibt dann hinter seinem Provider, und der Anwendungscode hantiert nur mit einer Referenz.
Ein privater Schlüssel, der nie das Dateisystem berührt, ist ein Schlüssel, den kein Volume-Leck kompromittiert.
Der Einstiegspunkt wird auf der OpenSSL-Seite konfiguriert, über die Konfigurationsdatei, die den gewünschten Provider aktiviert. Node.js stützt sich anschließend auf diesen Provider, um den Schlüssel beim Aufbau des TLS-Kontexts aufzulösen.
# 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 = 1Diese Umstellung ist keineswegs verpflichtend: Die meisten Deployments lesen weiterhin eine PEM-Datei. Sie öffnet jedoch eine lange erwartete Tür für Teams mit strengen Anforderungen an die Geheimnisaufbewahrung, die es bislang ablehnten, einen Produktionsschlüssel im Klartext auf einer Anwendungsplatte zu sehen.
Was die LTS-Linie nebenbei gewinnt
Version 24.21.0 portiert mehrere bereits auf der Current-Linie erprobte semver-minor-Ergänzungen zurück. Die Histogram-Objekte in perf_hooks erhalten statistische Hypothesentests und eine überarbeitete Implementierung, net.BlockList wird schneller, und util.MIMEType.parse() bekommt eine Variante, die bei ungültiger Eingabe null zurückgibt, statt eine Ausnahme zu werfen. Nichts Spektakuläres, aber ebenso viele Kanten weniger für Code, der bereits läuft.
Was bleibt
Beide Veröffentlichungen sind eher Wartung als Ankündigung: keine neue strukturierende API, aber eine resynchronisierte TLS-Kette und ein weiterer Sicherheitshebel für private Schlüssel. Richtig ist, das Upgrade auf die LTS 24.21.0 auf den Produktionsservern zu planen und dabei jene zu priorisieren, die ausgehende HTTPS-Verbindungen zu Dritten öffnen. Node.js in der Produktion zu betreiben, profitiert davon, diese kleineren Versionen wie Sicherheitsbausteine zu behandeln, gleichrangig mit einem Anwendungs-Patch.
Auf meinen Servern behandle ich Zertifikatswurzeln wie Abhängigkeiten: ein Upgrade, über das ich nicht diskutiere. Ich habe zu viele „unerklärliche“ Webhook-Ausfälle erlebt, die sich auf eine Laufzeitumgebung zurückführen ließen, die drei Jahre auf einem alten Wurzelspeicher verblieb. Was die STORE-Loader angeht, werde ich sie nicht überall aktivieren, aber für Projekte, in denen der TLS-Schlüssel echten Wert hat, ist das PEM von der Platte zu holen genau die Abwägung, die ich seit Langem empfehle. Das Härten eines Server-Grundgerüsts beginnt bei solchen Details. — Simon Janvier
Zum Weiterlesen: Node.js 24.21.0 & Node.js 26.8.2.
