Bevor eine Zertifizierungsstelle ein Zertifikat ausstellen kann, braucht sie einen öffentlichen Schlüssel, den sie beglaubigen soll. Diesen liefert der Antragsteller in einem Certificate Signing Request, kurz CSR, dem Zertifikatsantrag. Erzeugt werden Schlüsselpaar und CSR auf dem eigenen Rechner, meist mit dem Werkzeug OpenSSL. Dieser Artikel erklärt, was in einem CSR steht, welcher Schlüsseltyp sinnvoll ist, zeigt die Befehle Schritt für Schritt und beschreibt, wie man den privaten Schlüssel schützt.
Schlüsselpaar und CSR: worum es geht
Am Anfang steht ein Schlüsselpaar: ein privater Schlüssel, der den Rechner nie verlässt, und der dazugehörige öffentliche Schlüssel. Aus dem öffentlichen Schlüssel und den gewünschten Namen entsteht der CSR. Das Format heißt PKCS#10 (RFC 2986) und enthält:
- den Inhaber (Subject), etwa CN = www.beispiel.de,
- den öffentlichen Schlüssel,
- gewünschte Erweiterungen, vor allem die Liste der Domainnamen (Subject Alternative Name),
- eine Signatur mit dem privaten Schlüssel.
Die Signatur beweist der CA, dass der Antragsteller den passenden privaten Schlüssel besitzt, ohne ihn herauszugeben. Die CA übernimmt dann den öffentlichen Schlüssel und die geprüften Namen in das Zertifikat; wie das Ergebnis aussieht, zeigt X.509-Zertifikat einfach erklärt.
Welcher Schlüssel? RSA oder elliptische Kurve
Für Website-Zertifikate kommen zwei Verfahren infrage:
- RSA: seit Jahrzehnten verbreitet und von jedem Programm unterstützt. Öffentliche CAs verlangen mindestens 2.048 Bit; das BSI empfiehlt für neue Schlüssel mindestens 3.000 Bit. Zum Verfahren siehe RSA einfach erklärt.
- ECDSA mit elliptischen Kurven: Die Kurve P-256 bietet etwa dieselbe Sicherheit wie RSA mit 3.072 Bit, bei viel kürzeren Schlüsseln und schnelleren Signaturen. Daneben ist P-384 üblich; Schlüssel auf P-521 und Ed25519 nehmen öffentliche CAs dagegen nicht an. Mehr in elliptische Kurven.
Ein Größenvergleich zeigt den Unterschied: Der öffentliche Schlüssel von RSA-3072 ist 384 Byte lang, eine Signatur ebenfalls 384 Byte. Bei P-256 sind es 64 Byte für den Schlüssel und rund 64 bis 72 Byte für die Signatur. Für neue Websites ist P-256 heute die übliche Wahl; RSA bleibt sinnvoll, wenn sehr alte Geräte bedient werden müssen.
Privaten Schlüssel erzeugen
Mit OpenSSL 3 erzeugt dieser Befehl einen Schlüssel auf der Kurve P-256 und speichert ihn in der Datei server.key:
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out server.key
Für RSA mit 3.072 Bit lautet der Befehl:
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
Die Datei enthält den privaten Schlüssel im Textformat PEM, erkennbar an der Kopfzeile „BEGIN PRIVATE KEY“. Den öffentlichen Schlüssel kann man jederzeit daraus ableiten; umgekehrt geht das nicht.
Den Zertifikatsantrag (CSR) erstellen
Nun entsteht der CSR. Wichtig ist die Liste der Namen im Feld subjectAltName, denn nur dieses Feld werten Browser aus:
openssl req -new -key server.key -out server.csr -subj "/CN=www.beispiel.de" -addext "subjectAltName=DNS:www.beispiel.de,DNS:beispiel.de"
- -new -key server.key: neuer Antrag zum vorhandenen Schlüssel.
- -subj: der Inhaber. Bei Domainvalidierung genügt der Domainname; Angaben wie Organisation oder Ort übernimmt eine CA nur nach eigener Prüfung.
- -addext: fügt die gewünschten Domainnamen hinzu. Ohne diese Angabe enthält der CSR nur den CN.
Den CSR prüfen
Vor dem Einreichen lohnt ein Blick in den Antrag:
openssl req -in server.csr -noout -text -verify
Die Ausgabe sollte „verify OK“ (bei neueren Versionen „Certificate request self-signature verify OK“), den richtigen Subject, den Schlüsseltyp und die Namen unter „Requested Extensions“ zeigen. Ob Schlüssel, CSR und später das Zertifikat zusammenpassen, prüft man am einfachsten über einen Hashwert des öffentlichen Schlüssels:
openssl pkey -in server.key -pubout | openssl sha256
openssl req -in server.csr -pubkey -noout | openssl sha256
Stimmen beide Werte überein, gehören Schlüssel und Antrag zusammen. Zum Prinzip des Hashwerts siehe Hashfunktionen einfach erklärt.
Den privaten Schlüssel schützen
Der CSR ist öffentlich, der private Schlüssel nicht. Wer ihn kennt, kann sich als Ihr Server ausgeben. Deshalb:
- Den Schlüssel nie an die CA, per E-Mail oder in ein Ticketsystem schicken. Eine CA fragt nie danach.
- Die Datei nur für den Webserver lesbar machen, unter Linux etwa mit chmod 600 server.key.
- Für Kopien und Archive den Schlüssel mit Passwort verschlüsseln: openssl pkey -in server.key -aes256 -out server-geschuetzt.key.
- Für besonders wertvolle Schlüssel Hardware nutzen, etwa ein Hardware-Sicherheitsmodul.
- Bei jedem Verdacht auf Diebstahl das Zertifikat sperren lassen und einen neuen Schlüssel erzeugen, nicht den alten wiederverwenden.
Und mit Let’s Encrypt?
Wer Let’s Encrypt mit einem ACME-Client wie certbot nutzt, muss sich um all das meist nicht kümmern: Der Client erzeugt Schlüssel und CSR selbst, reicht den Antrag ein und erneuert alles automatisch. Einen eigenen CSR kann man trotzdem verwenden, etwa mit certbot certonly –csr server.csr. Wie der Ablauf aussieht, beschreibt ACME und Let’s Encrypt. Bei kommerziellen CAs kopiert man den Inhalt der Datei server.csr in das Antragsformular und erhält nach der Prüfung das Zertifikat.
Häufige Fragen
Kann ich denselben Schlüssel für mehrere Zertifikate verwenden? Technisch ja, aber besser nicht. Ein neuer Schlüssel bei jeder Erneuerung begrenzt den Schaden, falls ein alter Schlüssel unbemerkt kopiert wurde.
Was passiert, wenn ich den privaten Schlüssel verliere? Das Zertifikat ist dann wertlos. Sie erzeugen einen neuen Schlüssel und CSR und lassen ein neues Zertifikat ausstellen.
Muss ich Land, Ort und Firma in den CSR schreiben? Bei domainvalidierten Zertifikaten nicht. Die CA übernimmt nur Angaben, die sie selbst geprüft hat.
Funktionieren diese Befehle auch unter Windows? Ja, mit einer OpenSSL-Installation oder in der Linux-Umgebung WSL. Alternativ erzeugt Windows CSRs über die Zertifikatsverwaltung oder certreq.
Fazit
Ein CSR enthält den öffentlichen Schlüssel, die gewünschten Namen und eine Signatur, die den Besitz des privaten Schlüssels beweist. Mit zwei OpenSSL-Befehlen entstehen Schlüssel und Antrag, ein dritter prüft das Ergebnis. Entscheidend ist, die Domainnamen im Feld subjectAltName anzugeben und den privaten Schlüssel nie aus der Hand zu geben. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.
Quellen und weiterführende Links
- RFC 2986: PKCS #10 Certification Request Syntax (IETF)
- openssl-req (OpenSSL-Dokumentation)
- BSI TR-02102: Kryptographische Verfahren (BSI)
- Certificate Signing Request (Wikipedia)















Neueste Kommentare