Schlüsselpaar und CSR erstellen: Zertifikatsantrag mit OpenSSL

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.

Vier Schritte: Schlüsselpaar erzeugen, CSR mit öffentlichem Schlüssel und Namen erstellen, Prüfung durch die CA, Ausstellung des Zertifikats; der private Schlüssel bleibt auf dem Server.
Der Weg vom Schlüsselpaar zum Zertifikat.

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.

Balkendiagramm: RSA-2048 hat 256 Byte Schlüssel und Signatur, RSA-3072 je 384 Byte, die Kurve P-256 64 Byte Schlüssel und etwa 64 bis 72 Byte Signatur.
Größenvergleich von RSA und elliptischer Kurve P-256.

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.

Vier Zeilen: Inhaber, öffentlicher Schlüssel, gewünschte Erweiterungen mit den Domainnamen und die Signatur mit dem privaten Schlüssel.
Der Inhalt eines Zertifikatsantrags nach PKCS#10 (Beispielwerte).

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.

Rating: 5.00/5. From 21 votes.
Please wait...


IT-Berater und Softwareentwickler aus Deutschland mit mehr als 25 Jahren Erfahrung in Unternehmenssoftware. Schwerpunkt: Public-Key-Infrastruktur (PKI) und Zertifikats-Lebenszyklus-Management, dazu lokale KI und große Sprachmodelle. Betreibt techuni.de, Tech Crates und Student Life Online. Mehr auf carsten-kraft.com.