Update 123 OpenVPN Host Zertifikat RFC3280 nicht Regelkonform

[ummeegge]

Hallo Siggi,
hatte Core 120 zweimal komplett auf anderen Maschinen neuaufgesetzt (incl. OpenVPN und hab vor der 120er Veröffentlichung eine frische .iso mal testweise in der VM laufen lassen, hab testweise auch gerade das Core 124 image mit dem neuen Suricata neuinstalliert und überall war die ovpn.cnf upgedatet (denke die meinst du) mit den 4 (es sind nicht zwei) neuen strings drinne.
Das findest du auch in den Heads vom Core 120 --> https://git.ipfire.org/?p=ipfire-2.x.gi ... ore120#l75 . War da bei dir ein BackUP event. im Spiel ? Kann das ansonsten hier nicht nachvollziehen.

Auch wenn die Einträge schon da sind erscheint die Meldung immer noch da du die komplette PKI erneuern musst um diese "Warnung" loszuwerden. OpenVPN macht mit der 2.5er Version schluss mit '--ns-cert-type's, IPFire hat derzeit die 2.4.6 laufen, du findest im Thread den Entwicklungsstatus von der 2.5er frühestens bis dahin bleibt diese Meldung dann auch nur eine Warnung...

Kurz nochmal zu dem Diff, hier findest du die Änderungen:
https://git.ipfire.org/?p=ipfire-2.x.gi ... 6716e96f85

Liebe Grüsse,

UE

[Siggi]

Hmmm,

da könnte was wahres dran sein. Wir haben die Hardware ausgetauscht und haben den ipfire frisch installiert und danach ein aktuelles Backup der alten Maschine eingespielt. Dann war der Fehr wahrscheinlich schon auf den alten fires und durch den Restore ist er wieder in die neue mit übernommen worden.
Naja wir werden in absehbarer Zeit die 4 Zeilen in der ovpn.cnf ergänzen und die PKI neu machen. Danach solle es ja wieder passen.

Es reicht also wenn man die 4 Zeilen ergänzt und die PKI neu aufsetzt ?

Vielen Dank für deine Antwort

Siggi

[ummeegge]

Jo gerne,
die BackUP Funktionen für die OpenSSL Konfig für´s OpenVPN wurde auch schon gefixt und werden bei einem BackUP excluded (war auch in einem der 120er Updates), somit sollte das jedenfalls nicht mehr passieren.

Es gibt in dem Topic auch noch ein paar Ideen/Warnungen wie du dir eine funktionale ovpn.cnf nochmal über das Git ziehen kannst.

Grüsse,

UE

[bettman2000]

Hi,
aktuell habe ich ein seltsames Phänomen und kann im Forum nichts finden, vielleicht kann mir jemand helfen.

Hatte auch die RFC Meldung gehabt, meine ovpn.cnf hatte (ohne Backup / Restore) auch den alten Stand.
Daher habe ich x509 löschen durchgeführt und die ovpn.cnf aus dem Git verwendet, sogar noch ein reboot durchgeführt und anschließend neue Zertifikate erstellt.
Nun werden die Root-, Host- Zertifikate, als auch DH Parameter ordnungsgemäß erstellt, im WUI ist auch keine Fehlermeldung.
Allerdings habe ich bei DH = 2048 Bit auch ein TLS Zertifzierungsschlüssel, lösche ich über x509 wieder und erstelle neue Zertifikate mit der Auswahl 3072 oder 4096 Bit wird KEIN TLS-Authentifizierungsschlüssel im WUI angezeigt, auch ist nur bei 2048 Bit ein ta.key (/var/ipfire/ovpn/certs/ta.key) vorhanden.
/log/httpd/error_log sieht aus als ob alles fertig ist.

Jemand eine Idee warum der TLS-Authentifizierungsschlüssel nur bei 2048 Bit erstellt wird?

Gruß

[ummeegge]

Hallo bettman2000,
da gab es auch schon in einem anderen Topic im Forum allerdings nur bei 4096 DH-Parametern Probleme. Wenn du allerdinsg in den Erweiterten Einstellungen "tls-auth" anhackst, was auch gemacht werden muss wenn du den statischen key nutzen willst wird er, sofern nicht vorhanden, nochmal erzeugt.

UE

[bettman2000]

Hallo ummeegge,
vielen Dank für die Antwort. Glaube dann muss ich nochmal ein Forum Searchengine Kurs machen.
Habe wie von dir vorgeschlagen HMAC tls-auth aktiviert, dann war ein TLS-Authentifizierungsschlüssel mit 2048 bit OpenVPN static key vorhanden. Obwohl ich Diffie Hellman auf 3072 bit habe. (Will eigentlich 4096bit verwenden, nur zum schnelleren nachstellen setze ich 3072 statt 4096, da es sich mein System gleich verhält > 2048).
Auch wenn ich die x509 Zertifikate lösche, wird wieder ein TLS-Authentifizierungsschlüssel mit 2048 bit angezeigt, obwohl DH auf 3072 steht.

Wenn ich das Konzept richtig verstanden habe, ist ein 2048bit TLS Key nicht tragisch, da anschließend auch mit den gewählten DH Bits (4096) der die Connection authentifiziert und aufgebaut wird.
Ist daher eventuell der 2048 TLS Schlüssel beabsichtigt ?
Danke und Grüße Sven

[ummeegge]

Hallo Sven,
wenn ich DH-Parameter über 2048 bit erzeugen möchte mach ich das meist auf einer externen Maschine da es da schlicht schneller geht. Mit dem Kommando

Code: Select all

openssl dhparam -out dh4096.pem 4096

erzeugst du dir einen 4096bit Parameter, bei 3072 enstprechend den Wert ändern und lade mir das dann mittels IPFire´s OpenVPN Webuserinterface hoch, schau mal im unteren Bereich da findest du den entsprechenden Button, der Fire bennent ihn dann um und packt ihn an die entsprechende Stelle mit enstprechenden Permissions.
Der ta.key oder statische Key (signieren der Pakete) hat mit dem DH-Parameter (Sessionkey aushandeln) erstmal nichts zu tun und wird mit einem eigenen Kommando mittels OpenVPN erstellt

Code: Select all

openvpn --genkey --secret ta.key

, der hat somit immer 2048 bit.

UE

[bettman2000]

Hallo UE,

vielen Dank für die sehr gute Erklärung.
Jetzt habe ich verstanden wie es läuft und somit ist alles geklärt.

Gruß Sven

[khorrk130]

Wenn ich einen Diffie-Hellman Key größer 2048bit erstelle dauert es bei mir zu lange und ich bekomme auf der Weboberfläche ein Timeout. Wenn der Key erstellt wurde fehlt mir dann der TLS-Authentifizierungsschlüssel.

Das gleiche Problem habe ich auch. OpenSSL arbeitet zwar weiter an der Generierung auch wenn das WUI ein Timeout anzeigt, unter /var/log/httpd/error_log die genannten Zeichenfolgen angezeigt. Wenn die Erzeugung beendet ist, fehlt trotzdem, wenn der Diffie-Hellman Key größer 2048bit sein soll, der TLS-Authentifizierungsschlüssel. Das ist reproduzierbar.
Meine Abhilfe war, die Zertifikate mit Diffie-Hellman Key 2048bit zu erzeugen, dann einen neuen Diffie-Hellman Key größer 2048bit separat zu erzeugen, alternativ auch einen extern erzeugten zu laden. Funktioniert bei mir beides.
Da ich mich aber ohnehin nur mehr schlecht als recht durch englische Anleitungen quäle, wäre die Frage an mich, warum das so ist, verfehlt.

[ummeegge]

Grüss Gott,
ich schätze mal das ist dann ein "Script timed out before returning headers" Problem, manch Boards haben da ein Problem mit Entropie ?!
Probier doch mal den Patch:

Code: Select all

--- /srv/web/ipfire/cgi-bin/ovpnmain_core131.cgi	2019-04-21 19:30:08.089428603 +0200
+++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi	2019-04-21 19:46:52.017323192 +0200
@@ -1953,6 +1953,13 @@
 #	} else {
 #	    &cleanssldatabase();
 	}
+	# Create ta.key for tls-auth
+	system('/usr/sbin/openvpn', '--genkey', '--secret', "${General::swroot}/ovpn/certs/ta.key");
+	if ($?) {
+	    $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
+	    &cleanssldatabase();
+	    goto ROOTCERT_ERROR;
+	}
 	# Create Diffie Hellmann Parameter
 	system('/usr/bin/openssl', 'dhparam', '-out', "${General::swroot}/ovpn/ca/dh1024.pem", "$cgiparams{'DHLENGHT'}");
 	if ($?) {
@@ -1967,13 +1974,6 @@
 #	} else {
 #	    &cleanssldatabase();
 	}
-	# Create ta.key for tls-auth
-	system('/usr/sbin/openvpn', '--genkey', '--secret', "${General::swroot}/ovpn/certs/ta.key");
-	if ($?) {
-	    $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
-	    &cleanssldatabase();
-	    goto ROOTCERT_ERROR;
-	}
 	goto ROOTCERT_SUCCESS;
     }
     ROOTCERT_ERROR:

das hilft nun nicht gegen den Timeout sollte aber den ta.key erstellen bevor der dh-parameter erstellt wird.

Frohe Ostern.

UE

[BetaTester]

Ist dieser Fix in der Core134 enthalten? Ich habe Probleme ein TLS Zertifikat zu erzeugen...

[ummeegge]

Nein ist er nicht. Was verstehst du unter "TLS Zertifikat" ?

[BetaTester]

Nennt sich in dem Bild "TLS-Authentifizierungsschlüssel:"