Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 3 subscribers
  • Views 850 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Komisches Verhalten von OpenVPN-Server nach Zertifikatswechsel

newone

Guten Abend zusammen!

Ich habe ein kleines Problem mit meiner UTM, bzw. genauer: Dem OpenVPN-Server oder aber mit dem Zertifikat handling. Je nachdem wie man es betrachtet.

Kurz ein bisschen Background: Ich habe ein kleines Netzwerk mit DCs und unter anderem auch einer CA.
In dieser CA habe ich ein Template erstellt für eine Subordinate CA welches ich verwende um ein Sub-CA Zertifikat für die UTM zu erstellen.
Dieses Sub-CA Zertifikat habe ich in der Sophos importiert, sie verwendet es um erzeugte Zertifikate zu signieren.

Das Webserver Zertifikat der UTM habe ich ebenfalls von der gleichen RootCA signieren lassen:
Also auf einem Client PrivKey und csr erzeugt (alle DNS-Namen die das System verwendet sind als SANs eingetragen!), diesen (csr) dann bei der CA eingekippt; signierten pubkey zusammen mit dem private Key in ein p12 gepackt und das dann auf der UTM importiert. Das Zertifikat verwende ich für das Admin-Interface und für den OpenVPN-Server.

Soweit so gut, das habe ich schon lange so und funktioniert auch, bzw. funktionierte... Bis gestern, da ist mein Webserver Zertifikat abgelaufen. Kein Problem: Ich habe den ganzen Vorgang ja in meinem Wiki dokumentiert. Von wegen... Nachdem ich das neue Webserver Zertifikat importiert und für VPN und Webserver ausgewählt habe verhält sich OpenVPN... unerwartet. (Der webserver kommt damit super klar: Certchain ist intakt, Firefox etc. ist zufrieden, keinerlei Zertifikatswarnungen etc.)

Am Client erhalte ich eine unable to verify certificate Fehlermeldung. Daraufhin habe ich mir die Client-Config einmal angeschaut die ich übers Benutzerportal runterladen kann. Neuerdings steht im CA-Block "<CA>Yaddayadda</CA>" nicht mehr meine eigene RootCA sondern die CA die die UTM vor 12 Jahren als ich sie aufgesetzt hab erstellt hat. (Ja, ich habe noch das alte ovpn file und habe sie verglichen.)
Die Client Certs sind aber nach wie vor signed von der "Sophos Sub CA". Wird mir auch mit Certificate Chain angezeigt, wurden NICHT neu generiert beim austausch des Webserver Zertifikats. Dies lies sich einfach über das "Valid from Date" verifizieren.

Jetzt frage ich mich was da schief läuft?
Ich hab die Certificate Authority Liste doch gar nicht angefasst, warum wird jetzt eine andere CA in der OpenVPN config angegeben?
Ich habe das Gefühl hier einen "neueren" Bug gefunden zu haben, ich verwende dieses Setup und den im (privaten) Wiki dokumentierten Prozess schon wirklich lange... Hinter meinem Profil steht tatsächlich: "...(X509 User Cert) (regenerated) (regenerated) (regenerated) (regenerated) (regenerated) (regenerated)". :)

Achja:

Firmware version: 9.707-5

Vielleicht hat ja jemand eine Idee wie ich es hinbekomme das wieder die richtige CA verwendet wird.

Schönen Abend noch!



This thread was automatically locked due to age.
Parents
  • +1

    Also, mit viel fluchen und schimpfen hab ich mich da selber durchgewurstelt:
    1.) Ich hab die Datei /var/confd/res/openvpn/client.ovpn-default bearbeitet und dort in die <ca>-Section das Zertifikat der root und der subca eingetragen.
    Dadurch sind die Client configs die man übers Benutzerportal runterladen kann wieder sauber.
    2.) Damit der openvpn-server funktioniert musste ich noch einen hardlink(!!!, ein symlink funktioniert nicht) zum cert meiner root-ca erstellen:
    "ln /var/sec/chroot-ipsec/etc/ipsec.d/cacerts/REF_$ROOTCA.pem /var/sec/chroot-openvpn/etc/openvpn/ca.d/HASH_DER_ROOTCA.0"
    Den Hash der RootCA konnte ich über Printable Configuration herausfinden.Im webinterface -> Support -> Printable Configuration.
    Der Hash war unter: "site-to-site VPN" -> certificate management -> certificate authorities bzw. verification ca -> meta information -> subject DN hash (subject_hash)
    Damit tut mein VPN jetzt endlich wieder.

    Nur um das nochmal zu betonen:
    Das musste ich noch nie zuvor machen, bisher hat es einwandfrei übers Webinterface funktioniert. Keine Ahnung wo da der Fehlerteufel steckt, aber es... suckt.

Reply
  • +1

    Also, mit viel fluchen und schimpfen hab ich mich da selber durchgewurstelt:
    1.) Ich hab die Datei /var/confd/res/openvpn/client.ovpn-default bearbeitet und dort in die <ca>-Section das Zertifikat der root und der subca eingetragen.
    Dadurch sind die Client configs die man übers Benutzerportal runterladen kann wieder sauber.
    2.) Damit der openvpn-server funktioniert musste ich noch einen hardlink(!!!, ein symlink funktioniert nicht) zum cert meiner root-ca erstellen:
    "ln /var/sec/chroot-ipsec/etc/ipsec.d/cacerts/REF_$ROOTCA.pem /var/sec/chroot-openvpn/etc/openvpn/ca.d/HASH_DER_ROOTCA.0"
    Den Hash der RootCA konnte ich über Printable Configuration herausfinden.Im webinterface -> Support -> Printable Configuration.
    Der Hash war unter: "site-to-site VPN" -> certificate management -> certificate authorities bzw. verification ca -> meta information -> subject DN hash (subject_hash)
    Damit tut mein VPN jetzt endlich wieder.

    Nur um das nochmal zu betonen:
    Das musste ich noch nie zuvor machen, bisher hat es einwandfrei übers Webinterface funktioniert. Keine Ahnung wo da der Fehlerteufel steckt, aber es... suckt.

Children
No Data
Unfiltered HTML