[Problem] OpenVPN 2.4 Client mit PKCS12

sagenein

Neuer User
Mitglied seit
26 Feb 2017
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Randbedingungen:

- OpenVPN 2.4.0 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Apr 2 2017

- library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09

- pkcs12 exportiert.p12 (exportiert ist ein Platzhalter)

Das Problem:

Beim Start des Client kommt die Meldung: Enter Private Key Password

Dieses Problem mit der Kennwortabfrage gibt es nicht auf einem Linux-PC (x66_64).

Auf dem Linux-PC habe ich folgende Randbedingungen:

- OpenVPN 2.4.1 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2017
library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.10
- gleiche Clientkonfiguration

Wo ist der Knackpunk?
 
Wenn die p12-Datei kennwortgeschützt ist, wird wohl bei dem Desktop-System irgendwo im "keyring" das korrekte Kennwort hinterlegt sein und dann über irgendeinen (bei solchen Desktop-Systemen üblichen) Message-Bus ausgelesen werden für das Öffnen der PCKS12-Datei (ich unterstelle einfach mal, daß es sich in beiden Fällen um dieselbe Datei handelt und damit die (allzu offensichtliche) Antwort "Die Datei auf dem Desktop-System ist gar nicht kennwortgeschützt." nicht in Frage kommt).

Auch wenn die Box m.W. keine Möglichkeit für eine wirklich gegen alles gesicherte Speicherung eines Kennworts bietet, bleiben Dir trotzdem noch genug andere Möglichkeiten. Das geht beim Export der PKCS12-Datei mit dem FRITZ!Box-eigenen Kennwort los (damit verschlüsselt die Box auch ihren eigenen privaten Schlüssel, der zu ihrem Zertifikat gehört) und dafür braucht es dann nur ein simples Skript (plus ein Programm, was Du mit Freetz erstellen kannst), um dieses Kennwort an OpenVPN zu übergeben oder Du nimmst gleich das FRITZ!Box-Zertifikat her für die Authentifizierung (braucht auch wieder das Kennwort) oder Du verpaßt der FRITZ!Box ein eigenes Zertifikat (braucht auch das Kennwort), das neben den anderen TLS-Verbindungen (GUI, FTP, usw.) auch noch für OpenVPN verwendet werden kann und nimmst dann das. Es gibt so viele unterschiedliche Möglichkeiten, daß man die unmöglich alle aufzählen kann - sogar das platte Hinterlegen des richtigen Kennworts im Klartext oder gar eine PKCS12-Datei ohne Kennwort für den privaten Schlüssel kann man in Erwägung ziehen, auch wenn das natürlich die allerunsicherste Variante ist.
 
Nutzt hier niemand pkcs12 in Kombination mit Freetz?

Ich verwende diese Option von OpenVPN schon lange. Es gab nie Probleme mit Linux, Windows, FreeBSD.

Die Möglichkeit mit ca, cert, key zu arbeiten ist die Alternative.

Die p12-Datei ist nicht kennwortgeschützt. Das ist nicht beabsichtigt.
 
Zuletzt bearbeitet:
Die p12-Datei ist nicht kennwortgeschützt. Das ist nicht beabsichtigt.
Noch mal ganz langsam, damit ich das auch verstehe: Deine PKCS12-Datei ist gar nicht kennwortgeschützt und trotzdem will OpenVPN ein Kennwort für den privaten Schlüssel haben? Das wäre dann tatsächlich ein fetter Fehler, aber im OpenVPN und nicht irgendwo im Freetz.

Eigentlich sollte diese Forderung erst dann über die Password-Callback-Funktion gestellt werden, wenn die Eingabe des Kennworts auch wirklich erforderlich ist (so sehen das zumindest die OpenSSL-Funktionen vor). Warum macht das dann OpenVPN so komisch? Und warum um alles in der Welt macht das OpenVPN dann nur auf der FRITZ!Box so komisch und nicht unter Linux, Windows oder FreeBSD? Oder ist es am Ende gar das brandneue OpenVPN 2.4.1, was das verursacht und nun dafür sorgt, daß aus "Es gab nie Probleme mit Linux, Windows, FreeBSD." am Ende ein "Es gibt nur Probleme mit Linux (auf der FRITZ!Box)." wird?

Wobei auch "Das ist nicht beabsichtigt." hoffentlich nur für Deine eigene Situation gilt. Ein unverschlüsselter (und damit ungeschützter) privater Schlüssel ist schon eine recht zweischneidige Angelegenheit (hat sich ja offenbar auch AVM gedacht und im Rahmen der Möglichkeiten Vorkehrungen getroffen) ... wenn man sich sicher ist, daß niemand Zugriff auf die FRITZ!Box mit dem Key erhalten kann und wird oder wenn dieser Key tatsächlich "uninteressant" ist (was ich bei einem Key, der für die Authentifizierung bei einem OpenVPN-Server verwendet wird, jetzt nicht unmittelbar als Erstes annehmen würde), dann mag das angehen. Ansonsten ist der "minimale Mehraufwand" bei der Verwendung eines Kennworts für den privaten Schlüssel zumindest schon mal eine Hürde, die den "Finder" beim Verlust (auch eine unberechtigte Kopie wäre ein Verlust) zumindest noch vor die Aufgabe stellt, das Kennwort dafür ebenfalls zu "finden".

Aber wie auch immer ... es wäre tatsächlich spannend zu wissen, was der Punk dazu zu sagen hat (auch wenn ich selbst nicht weiß, wo der sich gerade herumtreiben mag). Allerdings wäre mir beim Spiel "Laß einen Buchstaben weg." auch noch eine Lösung eingefallen, bei welcher der letzte Buchstabe erhalten bliebe.
 
Zuletzt bearbeitet:
OpenVPN 2.4.1 ist nicht der Heilsbringer oder Übeltäter je nach Sichtweise. Die p12-Datei, um die es sich handelt, wurde von den Versionen VOR 2.4.1 korrekt mit Linux, Windows, FreeBSD behandelt.

Ja, ein Kennwortschutz dieser Datei (dient zu Testzwecken) ist nicht von mir vorgesehen und ich kenne auch die damit verbundenen Risiken.

Warum macht OpenVPN 2.4 auf der Box solche Zicken?

Ich tappe voll im Nebel.
 
Die Möglichkeit ca, cert und key statt pkcs12 zu nutzen führt auch nicht zum Ziel. Hartnäckig wird ein Kennwort für den privaten Schlüssel gefordert.

Einzig die "inline" Variante funktioniert wie gewünscht. Ich spreche hier von der Version 2.4 von OpenVPN.

Das gleiche Verhalten gibt es auch mit der Version 2.3.14 von OpenVPN. Nur die "inline" Variante ist nutzbar.

Anmerkung:

OpenVPN in Freetz nutzt keine ECDHE cipher für den control channel. Ist das so gewollt?
 
Hartnäckig wird ein Kennwort für den privaten Schlüssel gefordert.
Dann probiere doch einfach einmal, mittels "askpass" eine leeres Kennwort per Datei an OpenVPN zu übergeben, wenn der private Schlüssel gar nicht geschützt ist. Es ist ja nun nicht so kompliziert, eine Datei mit einem "newline" zu erzeugen und beim Aufruf zu übergeben ... zumindest als Test bzw. als "Workaround" sollte so ein Versuch ja möglich sein.

Wobei ... wenn es beim "Zusammenkopieren" der Konfigurationsdatei mit den X.509-Dateien als Inline-Files auch funktioniert, brauchst Du selbst ja keinen "Workaround".

Aber das will vielleicht nicht jeder (also den unverschlüsselten privaten Key irgendwo speichern und schon gar nicht in einer kompletten OpenVPN-Konfigurationsdatei) und wenn man an den "askpass"-Parameter einen FIFO übergibt (die Abfrage erfolgt nur einmal, bevor OpenVPN dann auf "daemon" umschaltet und ggf. gar keinen Zugriff mehr auf Console oder irgendwelche anderen Dateien hat, die dem verwendeten Daemon-Konto unzugänglich sind), dann kann man auch mit "richtigen" Kennwörtern arbeiten und muß die (zumindest für das "Lesen" durch OpenVPN) auch nicht als "regular files" speichern, wo andere dann "nachlesen" könnten. Ist das nur eine 1:1-Kopie von einer anderen Stelle im Dateisystem, macht das natürlich keinen wirklichen Unterschied, aber wenn man so ein Kennwort irgendwo "obfuscated" gespeichert hat und es nur für den Zeitpunkt des Öffnens der Datei "sichtbar" machen will, dann ist ein FIFO an der Stelle die bessere Lösung im Vergleich mit einer "normalen" temporären Datei, die i.d.R. auch nach dem Löschen noch Spuren hinterläßt.
 
Ich werde wohl meine Test mit Freetz/OpenVPN 2.4 an dieser Stelle beenden. Falls ich mal eine FB für OpenVPN einsetzen muss, gibt es ja eine,
wenn auch nicht befriedigende Lösung, OpenVPN 2.4 zu nutzen.

Generell werde ich auf OpenVPN 2.4 nicht mehr verzichten, egal auf welcher Plattform. In OpenVPN 2.4 gibt es zu viele "nette" Optionen.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,690
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.