Nach Update von 2.4.5 auf 2.5.1 keine Stagged CAs mehr bei OpenVPN?
-
Wir haben hier eine OpenVPN Instanz laufen, die historisch bedingt eine aus zwei CAs assemblierte 'Stagged' CA verwendet.
Hintergrund hierfür war, dass wir die Notwendigkeit hatten, durch den Tunnel Zertifikate weltweit zu erneuern (auch die CA!).Das lief bis Version 2.4.5 ohne Fehler/Auffälligkeiten.
Nach einem Update auf Version 2.5.0 oder jetzt 2.5.1 konnte sich kein Client mehr verbinden.
Fehlermeldungen siehe Bild 1.
Gestern bin ich dem Verdacht, dass die Stagged CA den Fehler verursacht haben könnte nachgegangen und fand meinen Verdacht bestätigt: Nehme ich die alte, erste, 2018 abgelaufene CA raus, verbinden sich die Clients wieder. Füge ich es wieder ein, kann sich wieder kein Client verbinden.Kann ab Version 2.5 generell keine Stagged CA mehr verwendet werden oder ist das ein Bug (oder mache ich etwas falsch)?!
-
@jürgen-garbe said in Nach Update von 2.4.5 auf 2.5.1 keine Stagged CAs mehr bei OpenVPN?:
Wir haben hier eine OpenVPN Instanz laufen, die historisch bedingt eine aus zwei CAs assemblierte 'Stagged' CA verwendet.
Ich vermute du meinst "stacked" oder unified, da stecken wahrscheinlich dann einfach zwei CAs in einem File drin? Oder wie soll ich mir das vorstellen?
@jürgen-garbe said in Nach Update von 2.4.5 auf 2.5.1 keine Stagged CAs mehr bei OpenVPN?:
Gestern bin ich dem Verdacht, dass die Stagged CA den Fehler verursacht haben könnte nachgegangen und fand meinen Verdacht bestätigt: Nehme ich die alte, erste, 2018 abgelaufene CA raus, verbinden sich die Clients wieder. Füge ich es wieder ein, kann sich wieder kein Client verbinden.
Das klingt schlicht danach, als wären die Clients von der alten CA unterschrieben und die neue ist nicht "die Gleiche / erneuert", sondern eine komplett neue CA. Oder worin unterscheiden sich die beiden CAs? Klingt irgendwie seltsam.
Kann ab Version 2.5 generell keine Stagged CA mehr verwendet werden oder ist das ein Bug (oder mache ich etwas falsch)?!
Ich vermute eher dass das
- entweder mit OpenVPN 2.5
oder - OpenSSL
zu tun hat. Nicht mit pfSense selbst. Man vergisst leider leicht, dass mit pfSense 2.5 auch OpenVPN von 2.4 auf 2.5 gewechselt hat und dort einiges anders geworden ist und auch die OpenSSL Library selbst aktuell(er) ist und ggf. eben einige Dinge nicht mehr mögen könnte. Daher sehe ich das eher in den beiden Komponenten aber nicht direkt am Core oder der UI.
Nochmal die Frage: Worin unterscheiden sich die CAs neu/alt und was ist da genau passiert/der Unterschied?
Cheers
- entweder mit OpenVPN 2.5
-
Ich vermute du meinst "stacked" oder unified, da stecken wahrscheinlich dann einfach zwei CAs in einem File drin? Oder wie soll ich mir das vorstellen?
Ja, sorry, hatte das aus der Erinnerung ohne nochmal nachzuprüfen reingeschrieben. Es sind 2 CAs einfach hintereinandergeschrieben, genau wie Du richtig vermutet hast.
Das klingt schlicht danach, als wären die Clients von der alten CA unterschrieben und die neue ist nicht "die Gleiche / erneuert", sondern eine komplett neue CA. Oder worin unterscheiden sich die beiden CAs? Klingt irgendwie seltsam.
Die angehängte, zweite CA ist eine komplett neue CA. Die Clients wurden von der neuen (angehängten) CA unterschrieben.
Der Hintergrund war wie gesagt, dass sowohl CA (die erste), als auch Client/Server-Zertifikate auszulaufen drohten und durch den Tunnel selbst erneuert werden mussten. Der einzige Weg, den ich damals fand (und der auch funktionierte) war:- Neue CA erstellen
- Neue Zertifikate für Server und alle Clients erstellen
- Auf dem OpenVPN Server das vorhandene, alte CA.CRT mit dem neuen ergänzen (= stacked CA)
- Das neue Server Zertifikat noch nicht verwenden (sonst hätte sich kein "alter" client verbinden können)!
- In diesem Zustand konnten nun die alten Clients verbinden und es konnten die mit der neuen CA unterschriebenen Clientzertifikate sowie das stacked CA.CRT auf den Client eingespielt werden
- Nachdem alle Clients auf diese Weise mit neuer CA.CRT und ihrem neuen Client Zertifikat ausgestattet werden konnten, konnte schließlich das alte Server Zertifikat (von der alten CA unterschrieben) durch das neue (von der neuen unterschrieben) ersetzt werden
Das so verwendete stacked CA.CRT mit der ersten, 2018 abgelaufenen CA lief nun bis pfsense 2.4.5 fehlerfrei. Mit dem Update auf >= 2.5 erschienen die genannten Fehlermeldungen und die Clients konnten nicht mehr verbinden.
Ich vermute eher dass das entweder mit OpenVPN 2.5 oder OpenSSL zu tun hat. Nicht mit pfSense selbst.
Das kann natürlich gut sein. Ich habe nur aktuell keine Idee, wie ich das ad hoc testen könnte.
Ich hoffe nur, dass der von mir oben beschriebene Weg zum Erneuern von CAs und Zertifikaten mittels stacked CAs nicht verbaut wurde... -
OK verzeih' mir aber das macht keinen Sinn. Nicht auf der pfSense generell und nicht beim CA Handling at all. CAs funktionieren so nicht.
Wenn du
Neue CA erstellen
Neue Zertifikate für Server und alle Clients erstellen
DAS schon gemacht hast, dann macht alles weitere keinen Sinn mehr, da deine Clients und der Server ALLE bereits gegen die neue CA ausgestellt sind. Dann muss auch nur diese neue CA ausgeliefert werden und fertig. Du versuchst hier - was du mit stacking meinst - zwei völlig autarke unterschiedliche CAs zu pushen und beide gleichberechtigt zu nutzen. Wenn das ging, dann vermute ich eher, dass das aus Glück vllt funktioniert hat, beabsichtigt war das aber sicherlich nicht.
Zwei CAs aneinander zu hängen macht man NUR dann, wenn man bspw. eine Intermediate CA hat, also eine 2. CA die von einer vorhandenen CA ausgestellt wurde (Master CA und Sub CA um einen Baum/baumartige Struktur aufzubauen quasi). Aber einfach platt 2 CAs auf dem Server zu shippen ist buggy at least.
Das so verwendete stacked CA.CRT mit der ersten, 2018 abgelaufenen CA lief nun bis pfsense 2.4.5 fehlerfrei. Mit dem Update auf >= 2.5 erschienen die genannten Fehlermeldungen und die Clients konnten nicht mehr verbinden.
Es lief wie gesagt vielleicht fehlerfrei aber nicht fehlerlos, denn die ganze Konfiguration ist an sich schon ein Fehler. CAs bzw. Zertifikatshandling funktioniert nicht so. Du stellst keinen neue CA aus und baust einen ganzen Sack voller Zertifikate, sondern du klickst einfach schlicht und ergreifend auf Verlängern/Renew der CA und "aktualisierst" damit das Ablaufdatum (einfach gesprochen). Damit man aber genau die Kasperei nicht ständig machen muss, erstellt pfSense aus gutem Grund eine CA auf 10 Jahre Gültigkeit, damit man den Kram nicht ständig machen muss :)
Meine Vermutung ist dass OpenVPN den Lapsus oder diese Mißkonfiguration im Zuge neuer OpenSSL Richtlinien/Versionen ggf. gefixt hat und deshalb der ganze Glitch nicht funktioniert.
Du tust dir aber einen größeren Gefallen, wenn du das ganze nochmal korrekt durchkonfigurierst. Was du außerdem suchst ist im Certificate Manager bei den CAs oder Zertifikaten das hier:
Der kleine Kringel ist für das Re-Issue/Renewal von Zertifikaten zuständig. Das führt eine Neuausstellung bzw. eine Verlängerung durch. Das neue CA Zert muss dann natürlich an die Clients rausgeschickt werden, daher sollte man das sinnvoll vorbereiten und den Leuten ggf. dann per Mail oder andere Wege ihre neue Konfiguration zur Verfügung stellen. Aber genau daher haben die CAs norm. eine Lifetime von 10 Jahren, damit das kein Mammutjob jedes Jahr wird. Die Client/Server Zerts sind da normalerweise auch nur 1-2 Jahre, da kann man den Wechsel dann einfacher durchführen, aber genau deshalb gibt es nun seit 2.5 einen Dienst, der die Validität von Zertifikaten prüft und benachrichtigt, wenn welche dabei sind abzulaufen, damit man genug Zeit hat den Tausch zu planen. :)
Cheers
\jens -
@jegr Zunächst erstmal herzlichen Dank für die gründliche und ausführliche Erklärung/Erläuterung!
Ich hatte damals keine andere Möglichkeit gesehen mit dem Ablauf der CA und der Client sowie Serverzertifikate umzugehen (2018). Dazu muss man folgendes berücksichtigen:
Es handelt sich um eine schon 2006 etablierte Fernwartungslösung für weltweit verbaute Maschinen. Diese verbinden per "Knopfdruck des Kunden" auf verschiedenste Weisen über genau einen Port durchs WAN auf unseren "Fernwartungsserver" (der früher ein Linuxserver war und heute eine pfSense-Instanz ist).
Mit drohendem Ablauf der Gültigkeiten musste ich nun "durch den Tunnel", ohne Hilfe der Kunden auf den Maschinen die Zertifikate erneuern und dabei gewährleisten, dass, wenn ich z. B. die erste Maschine aktualisiert hatte, sich diese mit den neuen Zertifikaten verbinden konnte und gleichzeitig alle anderen Maschinen mit den alten Zertifikaten immer noch verbinden konnten...
Das war das Schlüsselkriterium dabei, was ich nur mit Hilfe der Stacked-CA gelöst bekommen habe.
Die saubere Lösung, einfach durch die noch funktionierende alte Verbindung eine neue Instanz aufzusetzen hätte die Mithilfe der Kunden (Firewall, Portfreigabe/Weiterleitung,...) bedurft, was leider immer sehr fehleranfällig ist und somit ausschied.Mag sein, dass dies alles nur durch einen "Glitch" möglich war, ich bin jedoch heilfroh, dass ich die beschriebene Aufgabe so lösen konnte. Ich sehe auch im Nachhinein keine andere Möglichkeit unter den beschriebenen Bedingungen (bitte sei Nachsichtig mit mir...).
Gelernt habe ich jedenfalls daraus: vor meiner Rente läuft nichts davon mehr ab ;)
Viele Grüße und nochmals Danke!
Jürgen
-
@jürgen-garbe said in Nach Update von 2.4.5 auf 2.5.1 keine Stagged CAs mehr bei OpenVPN?:
Es handelt sich um eine schon 2006 etablierte Fernwartungslösung für weltweit verbaute Maschinen. Diese verbinden per "Knopfdruck des Kunden" auf verschiedenste Weisen über genau einen Port durchs WAN auf unseren "Fernwartungsserver" (der früher ein Linuxserver war und heute eine pfSense-Instanz ist).
Darf man fragen welche Hardware ihr in den Maschinen als VPN Router einsetzt?
Gelernt habe ich jedenfalls daraus: vor meiner Rente läuft nichts davon mehr ab ;)
-
Darf man fragen welche Hardware ihr in den Maschinen als VPN Router einsetzt?
Keine dedizierte Hardware, das macht die Windows-Maschinensteuerung nebenbei (nicht hauen!).
-
@jürgen-garbe Es ist was es ist und es war (so gewachsen) wie es war. Da gibt's ja keinen Grund jemand zu hauen für irgendwas :)
Bei solchen Lösungen muss man nur eben wissen, was man getan hat/tut und einen halbwegs brauchbaren Plan haben um mit den Auswirkungen umzugehen. Zertifikatshandling haben leider viele gar nicht mal so gut auf dem Schirm, daher ist mehr Aufmerksamkeit da sicher nicht schlecht.
Ich vermute aber jetzt mal einfach so dahin: OpenVPN hat(te) die beiden CAs einfach als CA Liste angenommen - was per se jetzt auch kein Problem sein dürfte. Eventuell ist aber jetzt in pfSense 2.5 der Zertifikatsmanager nicht mehr in der Lage zwei CAs in einen Eintrag zu speichern und kann das deshalb nicht an den VPN Server geben/auswählen.
Du könntest aber ggf. das CA File das du so zusammenkopiert hast als File auf der Sense ablegen und das dann in der Konfiguration via Custom Option Textfeld ein-/nachladen. Eventuell funktioniert es über diesen Weg dann noch.
-
@jegr Hm, ich habe jetzt mehrere Versuche getätigt und eine andere gültige CA mal vor, mal hinter die eigentliche gepackt. Es sieht so aus, dass nur die erste ausgewertet wird und somit das Feature "Stacked CA" m. E. aktuell nicht mehr funktioniert (wobei ich nicht weiß, ob das nun an der pfSense oder am OpenVPN-Package liegt).
Du könntest aber ggf. das CA File das du so zusammenkopiert hast als File auf der Sense ablegen und das dann in der Konfiguration via Custom Option Textfeld ein-/nachladen. Eventuell funktioniert es über diesen Weg dann noch.
Würde ich gerne versuchen, weiß aber leider nicht wie und wäre deshalb zur Klärung für konkrete Handlungsanweisungen dankbar.
-
@jürgen-garbe In /var/etc/openvpn liegt die Server Conf sowie deren zusätzliche Files. Dort gibts dan auch das serverX.ca file.
Entweder kann man dreckig dort mal das zusammenkopierte File reinstecken (einfach das File überschreiben) und den Server dann via UI neu starten (und schauen ob er hochkommt).
Soweit ich das kurz bei OpenVPN 2.4 überflogen habe, ist das dort gültig wenngleich nicht empfohlen (This file can have multiple certificates in .pem format, concatenated together.) -
Wahrscheinlich meinst Du mit 'serverX.ca' nicht genau diesen Dateinamen sondern etwas generisches...
So sieht es bei mir aus:
Welche Datei meinst Du? -
@jürgen-garbe Unterordner server1 sollte alles enthalten, was den Server betrifft. Da ist auch ein CA Ordner da sollte dann das Server Zert drin sein (in deinem Beispiel müsste das 377fb034.0 sein). Da müsste man jetzt schauen, was im config.ovpn drin steht ob dort ein CApath gepusht wird oder ein CA definiert ist. Aber da könnte man dann eines dazu legen und beide angeben. :)
-
Ja, das ist die CA Datei.
In der Config sehe ich nichts auffälliges, nur die übliche Zeile:
capath /var/etc/openvpn/server1/ca
Was ich so interpretiere, dass die CA eben aus diesem Verzeichnis geladen wird (wobei... der exakte Dateiname 377fb034.0 nirgends auftaucht).Es verhält sich so:
In der CA Datei finden sich, wenn im Cert Manager eine Stacked CA definiert wurde, auch vollkommen richtig beide Zertifikate -> GUI von OpenVPN arbeitet auf jeden Fall korrekt.
Nun gibt es 2 Fälle:
a) Die abgelaufene CA befindet sich an erster Stelle -> Clients (neue CA...) können nicht mehr verbinden.
b) Die aktuelle CA befindet sich an erster Stelle -> Clients (neue CA...) verbinden wieder.Ich habe auch versucht, Deinen Vorschlag umzusetzen und in der OpenVPN Config Datei die CAs inline einzufügen. Die Ergebnisse sind aber nicht wirklich zu interpretieren, da ja bei jedem (Re-)Start von OpenVPN das Config file neu gebaut wird und ich somit die ganz oben genannte "capath" Zeile nicht wegbekomme...
Für mich sieht das aktuell immer mehr danach aus, als ob bei der Anwendung von Stacked CAs diese nicht mehr wie 'ehemals' durchprobiert werden sondern nur noch das erste gefundene angewendet wird, womit das Konzept 'Stacked CA' nicht mehr anwendbar zu sein scheint.
-
@jürgen-garbe und einfach eine zweite ca als file zusätzlich in den CA Ordner packen?
-
Wird bei jedem Neustart gelöscht...
-
@jürgen-garbe sie muss ja das richtige Format haben (ist m.W. irgendwas gehashtes oder codiertes). Neustart des Service oder des Geräts?
-
@jegr Neustart des Service schreibt die in der OpenVPN Page definierten Daten (also auch das CA File) neu, Reboot bereinigt zusätzlich den Ordner was einer Löschung der manuell 'beigelegten' Files gleichkommt.
Ich habe mal mit Deinem Input bzgl. der Dateinamen gespielt und habe jeweils von alter und neuer CA die Dateinamen übernommen. Habe aber daraus keine neuen Erkenntnisse gewinnen können
