Wie man einen CSR in Node.js generiert

Dieses Tutorial zeigt Ihnen wie Sie einen CSR für eine Node.js-Anwendung erstellen. Node.js verfügt über kein integriertes Werkzeug zur CSR-Erzeugung. Deshalb erstellen Sie den privaten Schlüssel und den Certificate Signing Request mit OpenSSL auf dem Rechner, der Node ausführen wird, reichen den CSR bei Ihrer Zertifizierungsstelle (CA) ein und laden anschließend das ausgestellte Zertifikat mit fs.readFileSync() und https.createServer() in Ihre Anwendung.

Die folgenden Schritte funktionieren auf jedem Betriebssystem, das OpenSSL mitliefert – das gilt für alle aktuellen Linux-Distributionen, macOS und Windows (über die offiziellen OpenSSL-Binärdateien oder Git Bash). Moderne OpenSSL-Versionen signieren Anfragen standardmäßig mit SHA-256, sodass Sie kein zusätzliches Digest-Flag angeben müssen.

Schritt 1: Stellen Sie sicher, dass OpenSSL installiert ist

Prüfen Sie, ob OpenSSL auf dem Rechner verfügbar ist, der Ihre Node.js-Anwendung ausführen wird:

openssl version

Sie sollten eine Zeile wie OpenSSL 3.0.x oder neuer sehen. Wenn der Befehl nicht gefunden wird, installieren Sie ihn für Ihre Plattform:

• Debian, Ubuntu: sudo apt update && sudo apt install openssl
• RHEL, AlmaLinux, Rocky Linux, Amazon Linux: sudo dnf install openssl (oder sudo yum install openssl bei älteren Versionen)
• macOS: OpenSSL (auf manchen Versionen LibreSSL, OpenSSL 3, wenn über Homebrew installiert) ist bereits im Terminal vorhanden. Um die Upstream-Version zu installieren: brew install openssl@3.
• Windows: installieren Sie die offiziellen OpenSSL-Binärdateien, oder nutzen Sie Git Bash, das mit vorinstalliertem OpenSSL geliefert wird.

Schritt 2: Privaten Schlüssel und CSR generieren

Generieren Sie den Schlüssel und den CSR auf dem Rechner, der Node.js ausführen wird. Der private Schlüssel wird direkt neben dem CSR erstellt und muss auf diesem Rechner verbleiben. Diese Befehle woanders auszuführen und den Schlüssel anschließend hin- und herzukopieren, würde den Zweck eines privaten Schlüssels von vornherein untergraben.

Führen Sie den folgenden Befehl aus. Er erstellt in einem Schritt einen 2048-Bit-RSA-Privatschlüssel und einen passenden CSR, wobei der Subject-Eintrag und die Subject Alternative Names (SANs) direkt inline angegeben werden, sodass OpenSSL keine Rückfragen stellt:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Was jeder Teil bewirkt:

• -newkey rsa:2048 erzeugt einen neuen 2048-Bit-RSA-Schlüssel. 2048 Bit ist derzeit das Minimum, das öffentliche CAs akzeptieren; Sie können für einen größeren Schlüssel auch rsa:4096 verwenden oder auf ECDSA umsteigen (siehe unten).
• -nodes lässt den privaten Schlüssel unverschlüsselt, damit Node.js ihn beim Start lesen kann, ohne nach einer Passphrase zu fragen. Node’s https-Modul unterstützt zwar eine passphrase-Option für einen verschlüsselten Schlüssel, aber die Passphrase muss trotzdem irgendwoher auf dem Rechner kommen (eine Konfigurationsdatei, eine Umgebungsvariable oder ein Secret-Manager).
• -keyout und -out benennen die Dateien für den privaten Schlüssel und den CSR.
• -subj liefert den Zertifikats-Subject. Tragen Sie hier Ihren echten Firmennamen, Bundesland und Ort ein, nicht die Platzhalter. CN (Common Name) ist Ihre primäre Domain.
• -addext „subjectAltName=…“ listet jeden Hostnamen auf, den das Zertifikat abdecken muss. Öffentliche CAs validieren anhand der SAN-Liste, daher sollten Sie den Common Name hier ebenfalls angeben. Das Flag -addext erfordert OpenSSL 1.1.1 oder neuer, was jedes aktuelle Betriebssystem mitbringt.

Ersetzen Sie yourdomain.com überall durch Ihre tatsächliche Domain. Um weitere Hostnamen abzudecken, fügen Sie diese durch Kommas getrennt in die SAN-Liste ein, zum Beispiel DNS:api.yourdomain.com. Für ein Wildcard-Zertifikat geben Sie sowohl die Wildcard als auch die reine Domain an: DNS:*.yourdomain.com,DNS:yourdomain.com.

Wenn Sie einen ECDSA-Schlüssel bevorzugen (kleiner und schneller, mit P-256 weit unterstützt), generieren Sie den Schlüssel und den CSR stattdessen so:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Interaktiver Modus (ohne -subj)

Wenn Sie stattdessen möchten, dass OpenSSL Sie zu jedem Feld einzeln abfragt, lassen Sie das Flag -subj weg:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

OpenSSL fragt nach folgenden Angaben:

• Country Name (C): der zweistellige ISO-Ländercode Ihrer Organisation (zum Beispiel US).
• State or Province Name (S): der vollständige Name des Bundeslands oder der Provinz, in dem Ihr Unternehmen registriert ist (zum Beispiel California). Nicht abkürzen.
• Locality Name (L): die Stadt, in der Ihr Unternehmen registriert ist (zum Beispiel San Jose).
• Organization Name (O): der rechtliche Name Ihres Unternehmens (zum Beispiel GPI Holding LLC). Für ein DV-Zertifikat (Domain Validated) lassen Sie das Feld leer und drücken Enter.
• Organizational Unit Name (OU): seit September 2022 veraltet und wird von öffentlichen CAs ignoriert. Lassen Sie es leer.
• Common Name (CN): der vollqualifizierte Domainname (FQDN), den Sie absichern, zum Beispiel yourdomain.com. Für eine Wildcard verwenden Sie *.yourdomain.com.
• Email Address: optional. Lassen Sie es leer.
• A challenge password: veraltet. Lassen Sie es leer.

Schritt 3: Dateien finden und schützen

Listen Sie das aktuelle Verzeichnis auf, um zu bestätigen, dass beide Dateien erstellt wurden:

ls

Sie sollten zwei neue Dateien sehen:

• yourdomain.key: Ihr privater Schlüssel. Bewahren Sie ihn auf dem Server auf, sichern Sie ihn zuverlässig und geben Sie ihn niemals an jemand anderen weiter, auch nicht an die Zertifizierungsstelle. Wer im Besitz des Schlüssels ist, kann sich als Ihre Website ausgeben.
• yourdomain.csr: Ihr Certificate Signing Request. Dies ist die Datei, die Sie beim SSL-Anbieter einreichen.

Setzen Sie unter Linux oder macOS sofort strikte Berechtigungen für den privaten Schlüssel, sodass nur der Benutzer, unter dem Node.js läuft, ihn lesen kann:

chmod 600 yourdomain.key

Wenn Node.js unter einem dedizierten Servicekonto läuft (zum Beispiel node oder www-data), legen Sie auch den Besitzer so fest, dass der Prozess den Schlüssel lesen kann:

sudo chown node:node yourdomain.key

Schritt 4: CSR überprüfen (optional, aber empfohlen)

Bevor Sie ihn einreichen, prüfen Sie, ob der CSR den richtigen Subject und die richtigen SANs enthält und ob seine Signatur gültig ist. Damit wird die Anfrage lokal mit OpenSSL dekodiert:

openssl req -noout -text -verify -in yourdomain.csr

Bestätigen Sie, dass die Zeile Subject Ihre Angaben anzeigt, dass X509v3 Subject Alternative Name jeden erwarteten Hostnamen auflistet und dass die Signaturprüfung verify OK ausgibt. Der Signaturalgorithmus sollte sha256WithRSAEncryption lauten (oder ecdsa-with-SHA256 bei einem ECDSA-Schlüssel). Wenn Sie die Kommandozeile lieber nicht verwenden möchten, fügen Sie den CSR in unseren Online-CSR-Decoder ein, um dieselben Felder im Browser zu lesen.

Schritt 5: CSR einreichen

Um den CSR für Ihre Bestellung zu kopieren, geben Sie seinen Inhalt aus:

cat yourdomain.csr

Sie sehen einen Textblock wie diesen:

-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----

Kopieren Sie den gesamten Block einschließlich der Zeilen —–BEGIN CERTIFICATE REQUEST—– und —–END CERTIFICATE REQUEST—– (jede Markierung hat auf beiden Seiten fünf Bindestriche). Dieser gesamte Block ist Ihr CSR. Fügen Sie ihn während des Kaufvorgangs in das Bestellformular ein und bewahren Sie den passenden privaten Schlüssel auf dem Server auf.

Wenn Sie die Kommandozeile lieber nicht verwenden möchten, können Sie die Anfrage auch mit unserem Online-CSR-Generator erstellen. Beachten Sie, dass der private Schlüssel dabei in Ihrem Browser generiert wird – speichern Sie diesen Schlüssel daher selbst und übertragen Sie ihn auf den Node.js-Server.

Was passiert, nachdem die CA das Zertifikat ausgestellt hat

Sobald die CA den CSR validiert und das Zertifikat ausstellt, erhalten Sie in der Regel Ihr Serverzertifikat (eine .crt-Datei, benannt nach Ihrer Domain) sowie ein oder mehrere Zwischenzertifikate, manchmal zusammengefasst in einer .ca-bundle-Datei. Node.js lädt diese in JavaScript: Verketten Sie das Serverzertifikat und die Zwischenzertifikate zu einer einzigen fullchain.crt-Datei, lesen Sie diese dann mit fs.readFileSync() ein und übergeben Sie sie an https.createServer():

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('/path/to/yourdomain.key'),
  cert: fs.readFileSync('/path/to/fullchain.crt'),
  minVersion: 'TLSv1.2'
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end('Welcome to a Node.js HTTPS servern');
}).listen(443);

Dieses Fullchain-Muster wird in den meisten Produktivumgebungen verwendet. Die vollständige Anleitung (einschließlich eines Beispiels mit ES-Modulen, eines alternativen ca:-Array-Ansatzes und eines Express-Beispiels) finden Sie in unserem Tutorial zur SSL-Installation für Node.js.

Ein Hinweis zu Produktivumgebungen. Im Jahr 2026 laufen die meisten Node.js-Anwendungen, die öffentlichen Datenverkehr verarbeiten, hinter einem Reverse-Proxy oder Cloud-Load-Balancer (NGINX, HAProxy, Caddy, AWS ALB, Cloudflare, Fastly), der TLS am Netzwerkrand terminiert und einfaches HTTP oder HTTP/2 an Node auf einem hohen lokalen Port weiterleitet. In diesem Modell befindet sich das Zertifikat (und der oben erzeugte CSR) auf dem Proxy oder dem Load Balancer, nicht auf dem Node-Prozess selbst. Node.js TLS direkt terminieren zu lassen, ist für Entwicklung, interne Dienste und kleine Bereitstellungen völlig in Ordnung; für eine öffentliche Produktivanwendung ist es üblicher, TLS am Netzwerkrand zu terminieren.