node-forge begann als TLS-Implementierung in JavaScript und wird heute vor allem für seine PKI-Bausteine genutzt: Erzeugen und Parsen von X.509-Zertifikaten und CSRs, Lesen und Schreiben von PKCS#12-Bundles, RSA-Verschlüsselung und -Signaturen sowie ein ASN.1-Parser. Es läuft in Browsern und in Node.js gleich und enthält keinen nativen Code.
Über Ed25519 hinaus unterstützt es keine elliptischen Kurven. forge.pki stellt nur rsa und ed25519 bereit, und der Test bestätigte die Folge: certificateFromPem() wirft bei einem ECDSA-Zertifikat Cannot read public key. OID is not RSA., und publicKeyFromPem() wirft bei einem öffentlichen Schlüssel vom Typ EC Cannot read public key. Unknown OID. – obwohl sich dieselben Bytes mit dem eigenen ASN.1-Reader von forge problemlos parsen lassen. Code, der Zertifikate aus der Praxis untersucht, trifft ständig auf ECDSA-Schlüssel und braucht dafür einen anderen Parser; X509Certificate aus node:crypto oder der Zertifikats-Decoder kommen mit beiden Schlüsseltypen zurecht.
Bei RSA klappt das Zusammenspiel reibungslos, sobald die Parameter übereinstimmen. Von forge erzeugte Signaturen nach PKCS#1 v1.5 und PSS bestanden die Prüfung mit node:crypto; bei PSS müssen der Digest, der MGF1-Digest und die Salt-Länge auf beiden Seiten übereinstimmen, und forge verlangt, dass du alle drei angibst, wie es das Beispiel tut. Öffentliche Schlüssel lassen sich aus SPKI-, PKCS#1- und Zertifikats-PEM laden, private Schlüssel aus PKCS#8, verschlüsseltem PKCS#8, PKCS#1 und PKCS#12 – öffne Bundles im PFX-Inspektor, um zu sehen, was sie enthalten.
Ed25519-Signaturen von forge waren beim selben Seed byteidentisch mit denen von node:crypto. Der private Schlüssel liegt in forge in der erweiterten 64-Byte-Form vor (der Seed, gefolgt vom öffentlichen Schlüssel), sodass Bibliotheken, die den 32-Byte-Seed erwarten, nur die erste Hälfte brauchen.
Bei der Signaturprüfung waren die Parser schon mehrfach zu nachsichtig, und ein Fall ist noch offen. Das Advisory GHSA-86w9-cpqp-85rv (CVE-2026-85393), veröffentlicht im September 2026 ohne korrigiertes Release, meldet, dass die Prüfung von RSA-Signaturen nach PKCS#1 v1.5 in Versionen bis einschließlich 1.4.0 zusätzliche Elemente im Algorithmusbezeichner der DigestInfo ignoriert; dadurch lassen sich Signaturen für Schlüssel mit einem kleinen öffentlichen Exponenten wie 3 fälschen. Der Test reproduzierte diese Nachsicht: Ein Block mit korrektem Padding und einem zusätzlichen Element an dieser Stelle bestand die Prüfung in forge und wurde von node:crypto abgelehnt. Bis eine Korrektur erscheint, prüfe PKCS#1-v1.5-Signaturen mit node:crypto oder WebCrypto und vermeide RSA-Schlüssel mit dem Exponenten 3. Version 1.4.0 selbst behob die vorherige Runde – ein zusätzliches Feld nach dem Digest und nicht kanonische Ed25519-Signaturen wurden beide abgelehnt –, und Versionen vor 1.3.0 hatten frühere Fehler, die Signaturfälschungen ermöglichten (CVE-2022-24771, CVE-2022-24772).