VPN Zertifikat Error

[superwinni2]

Hallo Zusammen

ich habe eine OPNsense mit aktuell 18.7 im Einsatz. Ich hätte hier gerne einen und später mehrere VPN Server am laufen welche entweder via SSL/TLS bzw über SSL/TLS mit Benutzer/Passwort Abfrage funktionieren.

Habe bisher schon so eineige VPN Server eingerichet aber irgendwie hakt es hier etwas...

Was ich bisher gemacht habe:
OPNsense installiert und Grundkonfiguriert (IPs etc).
Dann habe ich unter System -> Trust -> Authorities eine CA (HauptCA) erstellt

Code Select Expand

2048,SHA256,365,CN = Haupt-CA,E = support@test.com,O= Pri,L = Zuh,S = BW,C = DE
Danach eine Unterzertifizierungsstelle (UnterCA) davon erstellt

Code Select Expand

2048,SHA256,365,CN = UnterCA,E = support@test.com,O = Priv,L = Zuh,S = BW,C = DE
Nachdem die Unterzertifizierungsstelle eingerichtet war habe ich ein ServerZertifikat für den VPN Server erstellt.


Nun habe ich den OVPN Server einrichten wollen:
Dafür habe ich folgenden Einstellungen verwendet:

Code Select Expand

Server Mode: Remote Access (SSL/TLS)
Protocol: UDP
Device Mode: tun
Interface: Any
Local Port: 1175
TLS Authentication: Haken bei "Enable authentication of TLS packets" und Automatically generate a shared TLS authentication key"
Peer Certificate Authority: UnterCA
Server Certificate: VPN-Server-Cert (UnterCA)
DH: 2048 bit
Encryption algorithm: AES128-CBC
Auth Digest Algorithm: SHA1 (160-bit)
Hardware Crypto: No Hardware Crypto Acceleration
Certificate Depth: Do Not Check

IPv4 Tunnel Network: 10.100.140.0/24
IPv4 Local Network: 10.100.100.0/24
Disable IPv6: Aktiviert

Dynamic IP: Aktiviert
Address Pool: Aktiviert
DNS Default Domain: test.test
DNS Server 10.100.100.64

Alles was ich nicht angegeben habe ist leer oder der default Wert bzw. halte ich für unwichtig für den aktuellen Moment.

Nun noch für den Benutzer ein Zertifikat erstellen welches an der UnterCA signiert ist und Fertig.

Nun zu meinem Fehler:
Ich kann die OVPN Config ohne Probleme exportieren und starten. Bekomme jedoch auf dem Server den Fehler:

Code Select Expand

openvpn[75278]: xxx.xxx.xxx.xxx VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=DE, ST=BW, L=Zuh, O=Pri, emailAddress=support@test.com, CN=HauptCA
und auf dem Client:

Code Select Expand

TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting


Erweitere Infos:
Wenn ich nun einfach den auf dem Server die Peer Certificate Authority auf "HauptCA" stelle, funktioniert die Verbindung (mit der oben erstellten config), ich kann jedoch keine Zertifikate mehr exportieren.

Nun meine Große Frage...
Warum das ganze? Wo liegt hier mein Denkfehler?
Leider brauche ich diese Zertifizierungsstruktur, da in meinem Produktivem Umfeld hier die "HauptCA" nicht die OPNsense ist sondern ein Linux system. Jedoch der Fehler dort genau gleich ist. Daher auch der Test mit einer seperaten OPNsense.

Danke für eure Hilfe und Gruß

[superwinni2]

Niemand eine Idee?

[JeGr]

Ist die UnterCA ggf. aus versehen nicht als Intermediate-CA der HauptCA erstellt worden? Das liest sich irgendwie ein wenig so. Self-signed cert in cert chain - da müsste man die Zertifikate prüfen, ob die Kette da sauber ist.

Evtl. mal alle Zerts exportieren und auf nem PC einspielen und da nachvollziehen ob die Chain OK ist. Oder erstelle dir noch ein server-zert bei der UnterCA und nutze das für die WebUI und schau im Browser nach, ob die Kette sauber ist.

[superwinni2]

Hi JeGr

Zertifikatskette ist korrekt und überall auch bekannt und ebenso gültig.

Wer will kann es ja wie bereits geschrieben selbst testen...
Einfach ein RootCA erstellen, davon ein UnterCA und dann wie beschrieben einrichten... (alles auf der OPNsense und nicht mit extra CertServern etc..)
Meine große Frage ist vorallem wo hier mein Denkfehler liegt...

Aktuell und vermutlich als ewiges Provisorium habe ich es nun erstmal so gelöst, dass ich eine komplett seperate RootCA erstellt habe und mit dieser die VPN-Clients signiere. So kommt weder ein Fehler und ich kann auch die Configs exportieren...

[JeGr]

Die UnterCA auszuwählen ist eigentlich korrekt. Hast du die Cert Depth mal auf 2 gestellt statt auf disabled?

Wir haben ein ähnliches Konstrukt auf einem pfSense Cluster mit genau dem Aufbau (Master VPN CA unterschreibt mehrere Projekt VPN CAs und die stellen die Certs für Server und Clients aus). Ich werds aber bei Zeit kurz ins OPNlab reinwerfen und versuchen.

[superwinni2]

Habe die Cert Depth bereits alles mögliche versucht... Alles leider ohne erfolg...

Nach meiner logik sollte auch alles korrekt sein...
Wäre echt cool und interessant wenn wir den Fehler irgendwie finden würden...

[lfirewall1243]

Hi,

ich hatte letztens das selbe Problem, habe den Verschlüsselungsalg. auf beiden Seiten verändert, gespeichert und danach wieder zurückgesetzt.

Nach der Vorgehensweise ging es wieder.

Vielleicht klappts ja bei dir auch :)

[superwinni2]

habe den Verschlüsselungsalg. auf beiden Seiten verändert, gespeichert und danach wieder zurückgesetzt.

Werde ich versuchen.. Komme aber wohl erst nächste Woche dazu...

[rainerle]

Hi,

da ich das gerade hinter mir habe:
- DynDNS für den uplink aktivieren, damit man das opnsense per DNS erreichen kann
- os-acme-client installieren und für den DNS Namen ein Server Zertifikat bei Let's Encrypt holen
- VPN IPSec Mobile Clients einrichten (IKVEv2)
- Auf den Clients per Bordmittel (auf Android mit StrongSwan Client) mit dem IKEv2 VPN per User/Passwort verbinden

Das ist die Kurzversion der Anleitung.
Eine lange Version habe ich mir hier zusammengesucht:
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-firewall-einrichten-337198.html
https://alephnull.uk/lets-encrypt-on-demand-ikev2-vpn-debian-ubuntu-ios-username-password-authentication

Der Vorteil der Lösung: Man muss keinen Client einrichten, es braucht nur User und Passwort

Ich habe zur User Verwaltung auf der OPNsense den freeradius plugin installiert und dann den Radius Server imt EAP-RADIUS verwendet.

Besten Gruß
Rainer

[JeGr]

@rainerle Wenngleich dankenswert für die Anleitung, ist das IPSec um das es hier nicht geht, denn der OP möchte ja eine OpenVPN Zertifikatskette. Und das hat nur marginal irgendwas mit Let's Encrypt, IPSEC und sonstigem zu tun. :)

[superwinni2]

Hallo zusammen

so wie es aussieht war die eine Woche "Auszeit" vor der OPNSense gar nicht so schlecht.

@rainerle: Leider wie JeGr bereits geschrieben hat.. Komplett falsches Thema angegriffen... Trotz allem herzlichen Dank für die Anleitung.

An den Rest (und vorallem an JeGr und lfirewall1243 ):
Herzlichen Dank für die Hilfe und das Auffinden des richtigen Weges zur Lösung  ;) :)
Ich habe es nun geschafft und nach meinem Freudentanz möchte ich es auch nicht vorenthalten... Die Lösung ist so einfach wie auch genial...
Habe wie lfirewall1243 erst versucht den Verschlüsselungsalgorhythmus zu ändern.. Leider ohne großen Erfolg... Habe dann jedoch als Fehler 

Code Select Expand

VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=DE, O=Guenthart, CN=OPNsense-CA erhalten...

Dann gedacht: Okay.. Fehler hat sich ja schonmals etwas verändert.. Schmeißen wir doch mal das große G an und suchen danach... Dann auf folgenden Bug gestoßen: https://redmine.pfsense.org/issues/2800

Klang ja schonmal alles leicht ähnlich nach meiner Konstellation und Problem...

So und nun die Lösung:

Ich habe auf meiner Haupt-OPNsense die Zertifikate geschnappt und hintereinander kopiert, so dass dies in etwa so aussah:

Code Select Expand

-----BEGIN CERTIFICATE-----
MIIFZDCCA0ygAwIgeGHTwWfsdFaFEfeFRBDMQswCQYDVQQGEwJERTES
[...]   Dies ist mein HAUPT-CA
gpjaGrrSFWEF*wefWSEF+feSAFtsWp3257LPagXN5aQf34G+YOv/NEjA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGADCCA+igAwIBAg4g5r6we1g61G61G165YDVQQGEwJERTES6
[...]   Dies ist mein UNTER-CA
QctqCAfjV7w1fsafsgRGSgASERaREGS/gASfgSAGrgDRGVQUg5I8GiMm+PxAn
hZU9Hw==
-----END CERTIFICATE-----

Dies habe ich dann erneut als Certificate Authority bei Server + Client hinzugefügt/importiert (diesmal mit dem Namen "Unter-CA als Kette").
Danach dies als "Peer Certificate Authority" bei Server + Client geändert. Das passende Clientzertifikat (welches von der Unter-CA signiert war da ich temporär ein komplett eigenes CA auf der OPNsense erstellt hatte) ausgewählt.

Und siehe da: Es funktioniert 8)

PS.: Was es mit der "Certificate Depth" genau aufsich hat: Keine Ahnung  ::) Ich kann es auf "Disabled", "One" oder "Two" stellen... Verbindung funktioniert immer...

[JeGr]

OK dann würde ich das aber definitiv als Bug abstempeln, denn dann funktioniert die Auswahl bzw. Zusammenstellung von OpenVPN bei größerer Zertifikatstiefe nicht, wenn du manuell die Zertifikatskette importieren/auswählen musst. Das macht dann nur begrenzt Sinn. Bin leider nicht dazu gekommen das nachzustellen weil hier durch langen Krankheitsausfall zu viel im Backlog ist, aber bei der pfSense ist es so, dass bei einer Intermediate CA die selbst in der Zert-Verwaltung erstellt wurde und die die Sense daher kennt, man bei OpenVPN die Intermediate auswählt, Zert-Tiefe auf 2 (Intermediate + CA) stellt (das ist die Prüfung des Clients/Servers gegen die CA ob das Zert auch von 2 Zerts abstammt und die Kette stimmt), man beim Export auch auf dem Client die komplette CA Tiefe mit Intermediate erhält und bei der Einwahl das auch geprüft wird. Scheinbar hat sich da entweder bei dir oder generell was eingeschlichen, was da reingrätscht aber schön dass es nun erstmal mit Workaround läuft ;) Denn wenns richtig läuft sollte die Depth Einstellung nicht egal sein ;)

[superwinni2]

Das die Zert-Tiefe nicht egal ist kann ich mir schon denken... Vielleicht erkennt er es aber auch nur als ein Zertifikat da ich beide in einen Eintrag kopiert habe?!?

Das dies ein Bug ist vermute ich auch stark... Da der Bug aber wohl schon seit einigen Jahren bekannt ist (zummindest bei pfSense) denke ich, dass sich die meisten die solch eine Konstellation haben sich damit abgefunden haben. Und so wird der Fehler wohl ignoriert bis er irgendwann tot ist...  :P


Meine Haupt-OPNsense läuft aktuell "noch" mit

Code Select Expand

OPNsense 19.1.1-amd64
FreeBSD 11.2-RELEASE-p8-HBSD
OpenSSL 1.0.2q 20 Nov 2018

Ich habe noch eine "Client-OPNsense" jene nur als VPN Client gilt damit ein fremdes Netzwerk auf meines zugreifen kann und hier habe ichheute Updates installiert und es steht auch folgendes in der Changelog:

Code Select Expand


o openvpn: obey verify-x509-name for remote access (user auth)
o openvpn: proper daemonize instead of background job
o openvpn: extract full CA chain for setup
o openvpn: missing "port" in protocol export

Vielleicht kommt man der Sache auch näher durch den 3. Eintrag... Aber dies alles nun nochmals durchzutesten habe ich aktuell weder Zeit noch Lust ob es nun besser ist... Vor allem auch da es ja nicht 100% mit meinem Fehler übereinstimmt.

[JeGr]

> die meisten die solch eine Konstellation haben sich damit abgefunden haben. Und so wird der Fehler wohl ignoriert bis er irgendwann tot ist...

Ich denke die meisten nutzen eher selten eine Zert-Chain die mit Zwischenzertifikaten arbeitet, daher tritt das auch eher selten auf - das wäre zumindest meine Vermutung. Bei pfSense gab es da dieses Ticket und später nochmal einen Patch wegen einem Problem mit der Zertifikatstiefe aber da läuft es seit 2.4 auch sauber (zumindest bei uns).

Aber wenn es erstmal läuft ist fein, vielleicht kann ich das ggf. nochmal nachstellen wenn ich dazu komme :)

[Mks]

Hi,

interessanter Thread.

Habe ähnliches beobachtet und bin jetzt wieder bei einem neuen Setup drübergestolpert.

Hatte meine "Peer CA" noch immer auf die RootCA und nicht auf die Intermediate welche dann das Server Zert ausstellt.
Damit hatte ich jetzt plötzliche ähnliche Probleme wie du obwohl ein laufendes Setup bereits seit Jahren läuft. Habs jetzt aber auch wieder hinbekommen.

fg