Cert Manager Erstellung von Zertifikaten mit Passwort
-
Hallo zusammen,
ich möchte gern Zertifikate in der selbst signierten CA mit einem Passwort erstellen. Leider kann ich diese Funktion in der pfsense nicht finden.
Gibt es eine solche Lösung oder ist diese in Planung?
Vielen Dank.
Viele Grüße
Tino -
Hallo Tino,
zu welchem Zweck? Die Schlüssel der Zertifikate im CM sind absichtlich ohne Passwort verschlüsselt, da man sie für die meisten Zwecke ohne braucht. Deshalb ist das keine Funktion, die abgedeckt ist. Es steht dir aber frei, den Schlüssel später wieder zu verschlüsseln, wenn du das unbedingt möchtest. Das Zertifikat selbst hat nie ein Passwort, lediglich sein Private Key ist im Normalfall verschlüsselt.
Grüße
-
Hallo JeGr,
die bisherige TinyCA bat die Funktion, bei der Erstellung eines Zertifikates das Zertifikat mit einem Passwort zu versehen, welches man beim Importieren angeben musste.
Der Grund ist, dass die Zertifikate per E-Mail versendet werden.Dort wurde der Schlüssel zusammen mit dem Zertifikat als p12 Datei gespeichert.
Viele Grüße
Tino -
Hallo!
Wenn du die Zertifikate für OpenVPN Clients benötigst, kannst du das "OpenVPN Client Export Utility" Paket installieren, dieses bietet die Funktion.
Grüße
-
Hallo Viragomann,
danke für den Tip.
Wir wollen aber keine OpenVPN Zertifikate benutzen. Es sollen reine ipsec Verbindungen sein.
Kann man diese Funktion nicht auch für den Cert Manager einbauen?Beste Grüße
Tino -
Hi,
habe mit IPSec auf pfSense keine Erfahrung. pfSense ist sehr auf OpenVPN ausgerichtet, dies und schlechte Erfahrung mit IPSec von früher waren der Grund, weswegen wir mit pfSense auch auf OpenVPN umgestiegen sind.
Das OpenVPN Client Export Utility ist für eben rein für OpenVPN gedacht. Damit du es nutzen kannst, musst du einen OpenVPN Server im SSL/TLS Modus eingerichtet haben und beim Exportieren des Zertifikats und des privaten Schlüssels (beides im gemeinsamen PKCS#12 Format) kommt die OpenVPN-Einstellung unweigerlich im zip-Archiv mit.
Ob du dir das antun möchtest, sei deine Entscheidung. Ich würde es einfach mit 7-zip verschlüsseln und aussenden.
Grüße
-
Um ein paar seltsame Ideen auszuräumen:
die bisherige TinyCA bat die Funktion, bei der Erstellung eines Zertifikates das Zertifikat mit einem Passwort zu versehen, welches man beim Importieren angeben musste.
Nochmals: ein Zertifikat hat NIE ein Passwort, es gibt immer nur den privaten Schlüssel, der ein Passwort hat. Bei deinem bisherigen Format (pkcs12) ist lediglich der Schlüssel in der gleichen Datei wie das Zertifikat als Paket gespeichert. Das ändert aber nichts an der Aussage.
Wir wollen aber keine OpenVPN Zertifikate benutzen. Es sollen reine ipsec Verbindungen sein.
Es gibt keine "OpenVPN" Zertifikate. Es gibt lediglich TLS/SSL Zertifikate nach x.509 (https://de.wikipedia.org/wiki/X.509).
Dass diese Zertifikate heute für relativ viele Einsatzgebiete genutzt werden, ändert nichts daran, dass im Grundprinzip als Datei betrachtet alles das Gleiche ist. Ob das nun ein Zertifikat für einen Webserver, IPSec, OpenVPN etc. ist, spielt dabei keine Rolle. Lediglich wird für manche das gelieferte Format eine Rolle spielen (.pem, .p12, etc. -> https://de.wikipedia.org/wiki/X.509#Dateinamenserweiterungen_f.C3.BCr_Zertifikate)Das Einzige, was tatsächlich Zertifikate unterschiedlich macht, sind die gesetzten Flags, was es für ein Zertifikat ist (CA, Server, Client). Aber auch hier ist es lediglich diesen Bits geschuldet, für was das Zert genutzt werden kann. Alles andere ist völlig gleich.
Ich weiß jetzt nicht WOFÜR es bei deinem Einsatzgebiet ein nochmals mit Passwort geschützter Key sein muss, kenne aber selbst KEINE VPN Appliance, die unbedingt für IPSEC ein Zertifikat mit passwortgeschütztem Key benötigt. Es würde auch keinen Sinn machen, denn die Anwendung/Appliance müsste jedes Mal beim Neustart o.ä. den Key neu in den Speicher laden, dabei entschlüsseln etc. und dabei ist im Normalfall kein User anwesend, der den eintippen kann. Somit würde man das Passwort auf dem gleichen Device hinterlegen, was den Key an der Stelle wieder vollkommen unnütz macht. Deshalb werden u.a. auch bspw. Webserver nicht mit einem TLS Key/Zert gesichert, der noch ein Passwort hat, da ansonsten bei jedem Webserver Neustart der Key eingegeben werden müsste. Und wenn nicht, müsste der Key im Klartext auf der Maschine vorhanden sein was wieder das Passwort als 2. Faktor unnütz macht.
Deshalb als Denkanstoß einfach mal nachsehen, OB das überhaupt sein muss oder ob es einfach nur "bisher so war". Es ist ansonsten auch kein Problem, wie schon geschrieben, dem Schlüssel im Nachhinein ein Passwort zu verpassen, für die meisten Einsatzgebiete aber einfach unnötig. Wenn es nur um den sicheren Transfer des Schlüssels geht, ist ein PW geschütztes ZIP wie Virago meint garantiert ebenso sicher. Und einmal eingespielt in der Anwendung, Appliance oder dem Keystore wird der Schlüssel in den allermeisten Fällen eh nie wieder genutzt.
Grüße
