Mit openssl self signed zertifikat mit config datei erzeugen

Aus bknowledgebase
Zur Navigation springen Zur Suche springen

Einleitung[Bearbeiten]

Die Erstellung und Verwendung von SSL/TLS Zertifikaten ist heute integraler Bestandteil einer jeden IT-Landschaft. Mit openssl lassen sich Zertifikate für alle Möglichen Zwecke erstellen.

Hier einige Hinweise dazu:


Voraussetzungen[Bearbeiten]

Ich gehe davon aus, dass man zumindest mit einer Konsole irgendeiner Art umgehen kann und, dass es klar ist, das Pfade und Namen abweichen können etc.

Weiterhin braucht man natürlich openssl. Das heißt z.B. einen Webserver mit openssl oder wie auch immer letztlich einen Ordner mit der openssl.exe, die man dann mit den Parametern und Optionen aufrufen kann die ich hier im Artikel erwähne.

Ich gehe weiterhin davon aus, dass man sich in seiner Konsolen/Powershellsession bereits in dem Ordner befindet in dem die openssl.exe liegt und dass alle Dateien im gleichen ordner liegen (natürlich nur übergangsweise, Zertifikate und vor allem private schlüssel sollten dann natürlich gesichert sein). Deshalb werden die Pfade hier meist auf den aktuellen ordner ./ verweisen.


Eigenes CA-Zertifikat erzeugen[Bearbeiten]

Das ist besser, da man damit dann die weiteren Zertifiate signieren kann/sollte. Viele Browser akzeptieren schon gar keine Zertifikate mehr zu denen kein übergeordnetes CA-Zertifikat existiert. Wo quasi Aussteller und Antragsteller gleich sind, auch wenn das prinzipiell möglich ist. Deshalb erstelle ich zunächst ein Zertifikat nur für die Ausstellung weiterer Zertifikate.


Erstmal einen privaten Schlüssel von 2048 Bit Länge erzeugen (Passwort wird abgefragt dazu. Gut merken):

openssl genrsa -aes256 -out myCA.key 2048

oder die "neue" Variante des Befehls:

openssl genpkey -algorithm RSA -out myCA.key -aes-256-cbc -pass pass:myPassword -pkeyopt rsa_keygen_bits:2048

genrsa ist hier das Kommando um einen RSA private key zu erzeugen. https://www.openssl.org/docs/manmaster/man1/genrsa.html


Und Zertifikat an sich erzeugen:

openssl req -x509 -new -nodes -extensions v3_ca -key .\myCA.key -days 1024 -out ca-root.crt -sha512


req steht in diesem Fall für "Request" und verarbeitet dabei entweder, so wie in diesem Fall, eine .CSR Anfrage weiter zu einem Zertifikat. Es ist auch möglich -req -new zu verwenden und kein .CSR mitzuliefern, dieses wird dann quasi implizit erzeugt, die Üblichen Informationen werden abgefragt und man bekommt direkt das Zertifikat. https://www.openssl.org/docs/manmaster/man1/openssl-req.html

Jetzt haben wir ein Zertifikat um weitere Zertifikate zu Signieren.

Zertifikat erstellen und Signieren[Bearbeiten]

Wir gehen wieder genauso vor, nur dass wir beim erstellen des Serverzertifikats jetzt dieses mit dem gerade erstellten CA-Zertifikat signieren

openssl genrsa -out myCert.key 4096
openssl req -new -key myCert.key -out myCert.csr -sha512

Jetzt haben wir eine neue CSR-Datei erstellt (-new) (beim letzten mal nur implizit). Die myCert.csr Datei kann jetzt gemeinsam mit der CA dazu verwendet werden um ein signiertes Zertifikat zu erstellen.

openssl x509 -req -in myCert.csr -CA ca-root.crt -CAkey myCert.pem -CAcreateserial -out myCert.crt -days 365 -sha512


Was hier vielleicht auffällt, ist dass ich hier anstatt des oft auftretenden openssl req -x509 jetzt openssl x509 -req verwendet habe. Das wird ein bisschen klarer wenn man in die Doku schaut: https://www.openssl.org/docs/manmaster/man1/x509.html -> Allerdings kurz gesagt ist der Befehl openssl x509 quasi eher für die weiterverarbeitung von bereits existierenden Zertifikaten gedacht. Ohne das folgende -req würde auch standardmäßig ein Zertifikat als Input erwartet. Durch die Option -req allerdings wird stattdessen ein CSR-File akzeptiert mit dem wiederum das Zertifikat erst erzeugt wird etc. So wird das etwas klarer.

Config File Verwenden[Bearbeiten]

Man kann auch einfach viele Optionen und Informationen zusammengefasst in ein "config-File" packen und dieses dann an openssl übergeben.

In ein Textfile einfach die gewünschte Config schreiben (hier in sslConfig.txt). Hier sogar mit "alternativeName(s)".

Das erspart einem ggf. etwas Tipperei.

Das einfügen der "alternativeName(s)" hat allerdings immer wieder Probleme bereitet. Es gibt noch einen anderen Weg, der für mich immer zum Ziel geführt hat. Siehe unter dem Punkt Alle Browser Glücklich machen in diesem Artikel.

Beispiel:

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=DE
ST=Hessen
L=Frankfurt
O=bknowledgebase
OU=bknowledgebase
emailAddress=bkluszynski@bknowledgebase.com
CN = bknowledgebase.de
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = bknowledgebase.de
DNS.2 = bknowledgebase.net


Folgender Powershell Befehl:

openssl req -new -sha256 -nodes -out meinCSR.csr -newkey rsa:2048 -keyout meinKey.key -config .\sslConfig.txt


erzeugt das notwendige .CSR und den private Key.


Jetzt das Zertifikat an sich:

 openssl x509 -in .\meinCSR.csr -out multi.crt -req -signkey meinKey.key -days 365

CSR auslesen[Bearbeiten]

Wenn man ein erstelltes CSR nochmal auslesen/Anzeigen möchte.


Beispiel:

openssl req -in mycsr.csr -noout -text

Alle Browser glücklich machen[Bearbeiten]

Es gibt Browser, die geben sich auch nicht zufrieden, wenn man ein Root-Certificate hat auf welches das Server-Certificate zeigt. Hier werden z.B. bei Opera oder Chrome diverse Meldungen angezeigt die in verschiedene Richtungen weisen. Es liegt meistens daran, dass die sogenannten "AlternativeName(s)" nicht eingetragen sind. Dieses Zusatzattribut eines Zertifikats enthält für gewöhnlich die Subdomains, die man ggf. mit absichern will. Es gibt hier aber Browser die beim Vergleichen der Aktuellen URI mit dem Zertifikat nicht den Common-Name vergleichen, sondern die direkt in die "AlternativeNames" schauen. Wenn diese nicht existieren wird das Zertifikat als unsicher eingestuft.


Umsetzen kann man es ganz einfach wenn man es dann weiß :).

1. Erstelle ein File z.B. extfile.cnf mit den gewünschten Alternativen Namen als inhalt. (Als 1. Namen einfach 'nochmal' das eingeben was unter Common Name angegeben wurde)

extfile.cnf:

subjectAltName=DNS:myDomain.net,DNS:www.myDomain.net


2. Benutze so wie schon vorher einfach das entsprechende CSR und das root-CA-Zertifikat um ein Signiertes Zertifikat zu erstellen, nur mit dem unterschied, dass du jetzt noch dieses "extfile" mitgibst um das Zusatzattribut "AlternativeName(s)" mit hinzuzufügen.

openssl x509 -req -in .\myCSR.csr -CA ./root-CA.crt -CAkey ./myCA.key -CAcreateserial -out myNewServerCert.crt -days 365 -sha512 -extfile ./extfile.cnf

Dann nur das Passwort für die Nutzung des root-zertifikats bzw. des Schlüssels eingeben und alles wie gehabt eingeben. Voila. Jetzt akzeptieren meist alle Browser das Zertifikat solange in der aktuellen Umgebung (Client/Domäne etc.) das Root-Zertifikat als Vertrauenswürdiges Stammzertifizierungszertifikat hinterlegt ist.

Zertifikat mit Private Key in .p12-Datei exportieren[Bearbeiten]

z.B. für S/MIME Zertifikate die beim User in Outlook (o.ä.) Importiert werden sollen. Hier werden Zertifikat und private Key in eine .p12-Datei gepackt.


openssl pkcs12 -export -in smime.crt -inkey smime.key -out smime.p12

Für die Erzeugung von S/MIME E-Mail-Verschlüsselungszertifikaten ist auch das ein oder andere zu beachten. Hierzu ein eigener Artikel siehe: E-Mail Zertifikate SMIME Outlook TLS erzeugen

Weitere Hinweise[Bearbeiten]

Was hier vielleicht auffällt, ist dass ich hier anstatt des oft auftretenden openssl req -x509 auch manchmal openssl x509 -req verwendet habe. Das wird ein bisschen klarer wenn man in die Doku schaut: https://www.openssl.org/docs/manmaster/man1/x509.html -> Allerdings kurz gesagt ist der Befehl openssl x509 quasi eher für die weiterverarbeitung von bereits existierenden Zertifikaten gedacht. Ohne das folgende -req würde auch standardmäßig ein Zertifikat als Input erwartet. Durch die Option -req allerdings wird stattdessen ein CSR-File akzeptiert mit dem wiederum das Zertifikat erst erzeugt wird etc. So wird das etwas klarer.


Um das nochmal zu unterstreichen hier noch ein Beispiel mit der klaren "Rollenverteilung" der Befehle.

1. Erzeuge einen privaten Schlüssel mit RSA-Algorithmus und 4096 Bit Länge

openssl genrsa -aes256 -out test.key 4096

2. Erzeuge ein CSR-Request-File nach x509 Standard

openssl req -new -key ./test.key -out ./test.csr

3. Erzeuge ein Zertifikat aus dem CSR-File und dem Schlüssel

 openssl x509 -in ./test.csr  -out test.crt -signkey ./test.key


Hier wird immer standardmäßig das PEM Format implizit angenommen. Das heist .key und .crt sind eigentlich im PEM Format. Nur für die bessere Unterscheidbarkeit werden sie oft so benannt. Allerdings sieht man so nicht am namen ob es das PEM Format ist, da gibts auch noch andere, darauf gehe ich hier aber nicht ein.

WENN man beim CSR-Request erstellen (Punkt 2.) das explizite -x509 weglässt, wird Punkt 3 nicht funktionieren, da hier dieser Standard erwartet wird. Wenn man auch in Punkt 3 nicht über x509 geht sondern als Alternative

openssl req -in ./test.csr -out test.crt -key ./test.key versucht wird das funktionieren, allerdings kann man mit dem Zertifikat nicht viel anfangen. Ich habe jedenfalls noch nie gesehen, das man dieses Zertifikat verwenden kann.


Und zu guter Letzt. NUR mit dem Befehl openssl x509... kann man zu einem Zertifikat ein CA Zertifikat hinzufügen, bzw. ersteres mit letzterem Signieren. Hier gibt es die Optionen/Comamndos -CA und -CAkey.

Man benötigt also immer beides um zum Ziel zu gelangen. Falls es noch nicht aufgefallen ist. Letztlich wird aber immer der letzte Befehl openssl x509... zum erzeugen verwendet. Also ein x509 Zertifikat mit der strengen Hierarchie so wie man es von Webseiten etc. kennt.

Zertifikate Verteilen[Bearbeiten]

Die Zertifikate müssen dann eben noch an die Clients verteilt werden. Z.B. Via Active Directory.

H@ppy H@cking