30.01.2023, aktualisiert am 28.03.2023

5515

Mobile Clients mit Client Certificate authentifizieren

Guten Abend zusammen,
es geht um eine OPNsense (23.1-amd64) auf einem Mini-PC (Single Node). Es soll mit Hilfe des VPN Server ein IPSec IKEv2 für Mobile Clients bereitgestellt werden. Die Besonderheit in meinem Fall ist, dass die Authentifizierung mit Hilfe eines Clients Certificate erfolgen soll.

Ausgangslage sind die Anleitungen und zwei Beiträge.
IPsec VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
So, OPNsense Test war, wie zu erwarten, ebenso erfolgreich wie das Setup der pfSense oben.
OPNSense VPN IKEv2. läuft einfach nicht
IKEv2 VPN Authentifizierungsfehler

Nachschlagwerke:
https://blog.designed79.co.uk/wp-content/uploads/2021/01/VPN-IKEv2-with- ...
https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-ea ...
https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-eaptls.html

Nachstehend mein Vorgehen auf der OPNsense

Vorbereitungen CA

System:Trust: Authorities: Eine neue CA mit dem Namen "OPNsense CA1" mit den Default Werten angelegt. Als Common Name "internal-ca" gewählt.

System: Trust: Certificates: Ein neues Zertifikat vom Typ "Server Certificate" mit dem Descriptive name "IPSec Cert" erstellt. Dort als Common Name "opnsense01.sub.test.de" eingetragen. Als "Alternative Names" den Type "DNS" ausgewählt und jeweils als Wert "opnsense01" und "opnsense01.sub.test.de" hinterlegt.

Einen Testbenutzer "Dani" angelegt. Anschließend in den Einstellungen ein Client Certificate mit Hilfe der CA "OPNsense CA1" generiert. Dort habe ich als Descriptive name "Test1" eingetragen. Als "Common Name" und "Alternative Names" vom Type "DNS" jeweils den Zeichen "Dani" eingetragen.

Konfiguration IPSec Phase 1

Konfiguration IPSec Phase 2

Konfiguration des Windows Server 2022 als Client

Das Client Certificate des Benutzers "Dani" als PFX von der OPNsense exportiert.
Mit einem Benutzer am Windows angemeldet. Das PFX File in dem Certifcate Store des Users im Bereich "Personal Certificate" importiert. Den Private Key als "exportierbar" markiert (sicher ist sicher).
Das Certifcate der CA "OPNsense CA1" von der OPNsense exportiert, auf den Windows Server kopiert und dort in dem Certificate Store der Machine unter "Vertrauenswürdige Stammzertifizierungsstellen" importiert.
Prüfung der Zertifizierungspfad des Client Certificates erfolgreich validiert.
Eine neue VPN Verbindung hinzugefügt.

Bypassing Server Certificate Validation for Troubleshooting konfiguriert, da keine CRL zur Verfügung gestellt wird. Referenz dazu ist Windows RAS Fehlercode: 13801

Fehlermeldung
Egal mit welche Authentication Method ich in der Phase1 von IPSec auf der OPNsense konfiguriere, die Fehlermeldung ist immer die Selbe:

Einzig mit der Authentication Method "RSA (local) + EAP-TLS (remote)" kann ich eine Verbindung aufbauen. Allerdings juckt es die OPNsense nicht, wenn dass Client Certificate a) nicht mehr dem User zugewiesen ist. b) auf der CRL steht. c) gelöscht wurde. Ebenfalls funktioniert die Authentication Method "EAP-MSCHAPV2" in Kombination mit Pre-Shared-Keys von Typ EAP. Wie es auch in den Anleitungen von @aqui beschrieben wird.

Ich habe gesucht und gesucht und gesucht und komme den Fehler nicht auf die Spur. Mehrfach die Zertifikate neu angelegt, die IPSec Konfiguration neu aufgebaut, etc.

Kann mir jemand sagen, was ich falsch gemacht habe? Alternativ gerne auch eine funktionierende Anleitung zu dem Vorhaben.

Gruß,
Dani

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 5745519444

Url: https://administrator.de/forum/mobile-clients-mit-client-certificate-authentifizieren-5745519444.html

Ausgedruckt am: 30.12.2024 um 16:12 Uhr

21 Kommentare

Neuester Kommentar

"opnsense01.sub.test.de" ist kein DistinguishedName sondern ein FQDN, ein DistinguishedName wäre bspw. Im einfachsten Fall /CN=opnsense01.sub.test.de. Mit oder ohne Slash, musst du schauen, habe gerade keine OPNSense im Zugriff.
Aber die OPNSense Logs zeigen dir eigentlich detailliert was beim Login falsch läuft.

Gruß wurstel

Moin @5175293307,
Auslöser für diese Konfiguration ist das Handbuch der OPNsense:
https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-eaptls.html#phase- ...

Unabhängig davon finde ich den DistinguishedName des Zertifikats für den Server über System: Trust: Certificates heraus. Dort gibt es eine Spalte mit dem Namen "Distinguished Name" (siehe 2. Screenshot in der Frage). Aber keine Form eines DN lässt das Eingabefeld zu:

/CN=opnsense01.sub.test.de
CN=opnsense01.sub.test.de

Es erscheint immer folgende Fehlermeldung:

Auch die Anzahl der wählbaren Attribute ist überschau:

Nachstehend exemplarisch das Logfile von VPN: IPsec: Log File zu einem Anmeldeversuch:

Date Severity Process Line
2023-01-31T12:31:15	Informational	charon	06[NET] <con2|21> sending packet: from 46.x.y.z[4500] to 65.x.y.z[4500] (80 bytes)	
2023-01-31T12:31:15	Informational	charon	06[ENC] <con2|21> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]	
2023-01-31T12:31:15	Informational	charon	06[IKE] <con2|21> configured EAP-only authentication, but peer does not support it	
2023-01-31T12:31:15	Informational	charon	06[IKE] <con2|21> peer supports MOBIKE	
2023-01-31T12:31:15	Informational	charon	06[IKE] <con2|21> initiating EAP_TLS method (id 0xA4)	
2023-01-31T12:31:15	Informational	charon	06[CFG] <con2|21> selected peer config 'con2'	  
2023-01-31T12:31:15	Informational	charon	06[CFG] <21> looking for peer configs matching 46.x.y.z[%any]...65.x.y.z[65.x.y.z]	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> received 21 cert requests for an unknown ca	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> received cert request for "C=DE, ST=XX, L=YY, O=ZZ, E=hostmaster@domain.de, CN=internal-ca"	  
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> received fragment #2 of 2, reassembled fragmented IKE message (928 bytes)	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> parsed IKE_AUTH request 1 [ EF(2/2) ]	
2023-01-31T12:31:15	Informational	charon	06[NET] <21> received packet: from 65.x.y.z[4500] to 46.x.y.z[4500] (436 bytes)	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> received fragment #1 of 2, waiting for complete IKE message	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> parsed IKE_AUTH request 1 [ EF(1/2) ]	
2023-01-31T12:31:15	Informational	charon	06[NET] <21> received packet: from 65.x.y.z[4500] to 46.x.y.z[4500] (580 bytes)	
2023-01-31T12:31:15	Informational	charon	06[NET] <21> sending packet: from 46.x.y.z[500] to 65.x.y.z[500] (393 bytes)	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> sending cert request for "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3"	  
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> sending cert request for "C=US, O=Let's Encrypt, CN=R3"	  
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> sending cert request for "C=DE, ST=XX, L=YY, O=ZZ, E=hostmaster@domain.de, CN=internal-ca"	  
2023-01-31T12:31:15	Informational	charon	06[CFG] <21> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> 65.x.y.z is initiating an IKE_SA	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> received Vid-Initial-Contact vendor ID	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> received MS-Negotiation Discovery Capable vendor ID	
2023-01-31T12:31:15	Informational	charon	06[IKE] <21> received MS NT5 ISAKMPOAKLEY v9 vendor ID	
2023-01-31T12:31:15	Informational	charon	06[ENC] <21> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]	
2023-01-31T12:31:15	Informational	charon	06[NET] <21> received packet: from 65.x.y.z[500] to 46.x.y.z[500] (1104 bytes)

Die Meldung "received 21 cert requests for an unknown ca" wird auch protokolliert, wenn ich den Zugriff umstelle auf EAP-MSCHAPV2 + VPN: IPsec: Pre-Shared Keys.

Gruß,
Dani

Ich bin schonmal soweit gekommen das der Win 10 Client zumindestens nur anmeckert das er das Client Zertifikat nicht finden kann.

Das Client Zertifikat wurde aber im .p12 Format von der OPNsense exportiert und per Doppelklick in den User bezogenen Zertifikatsspeicher importiert.

Das kann nur noch ein kleiner Kinken irgendwo mit der Zertifikatszuordnung sein...?!

Die OPNSense kann offensichtlich keine Client-Auth mit EAP-TLS von Windows 10 aus laut der Compatibility-Matrix hier
https://docs.opnsense.org/manual/how-tos/ipsec-rw.html#vpn-compatibility
Sagt auch die Fehlermeldung

configured EAP-only authentication, but peer does not support it

Komisch wenn da ein strongswan im Background werkelt sollte man das eigentlich zum laufen bringen wenn man es auf der Konsole customized.

Mit ner PfSense geht es über EAP-TLS einwandfrei mit Certificate only. Shiet OPNSense ....

Bleibt bei der OPNSense nur RSA(Local) + EAP-TLS-Remote damit geht es hier auch wie bei dir.

@aqui
Danke für deinen Referenz Test.

Hast du das Zertifikat deiner OPNsense CA an dem Windows Rechner als Vertrauenswürdige Stammzertifizierungsstelle im Computerkonto hinzugefügt? So dass der Zertifizierungspad vollständig ist. Neustart nicht vergessen.

@5175293307
Danke auch für deinen Test! Die Matrix habe ich nicht gefunden oder übersehen.

Komisch wenn da ein strongswan im Background werkelt sollte man das eigentlich zum laufen bringen wenn man es auf der Konsole customized.

Du meinst die Konfigurationsdatei manuell überarbeiten? Dann wäre deine Datei von der pfSense natürlich wertvoll. Kannst du diese hier posten? Alternativ ziehe eine pfSense am Weekend als VM hoch.

Gruß,
Dani

Nee die pfSense kann es out of the box ohne customizing.

Aber RSA(Local) + EAP-TLS(Remote) tut es ja auch auf der OPNSense, was missfällt dir daran? Hier wird der Client ja auch per Zertifikat authentifiziert.

Moin,

Nee die pfSense kann es out of the box ohne customizing.

du meinst, dass es nicht nur von der Konfigurationsdatei abhängt sondern auch von der Application selbst?! Hmm...

Aber RSA(Local) + EAP-TLS(Remote) tut es ja auch auf der OPNSense, was missfällt dir daran? Hier wird der Client ja auch per Zertifikat authentifiziert.

Das war meine zwei Idee. Hier bei gibt es allerdings drei vermeidliche Probleme:

Einzig mit der Authentication Method "RSA (local) + EAP-TLS (remote)" kann ich eine Verbindung aufbauen. Allerdings juckt es die OPNsense nicht, wenn dass Client Certificate a) nicht mehr dem User zugewiesen ist. b) auf der CRL steht. c) gelöscht wurde.  

Wobei mir noch nicht ganz klar ist worin bei der OPNsense der Unterschied zwischen EAP-TLS und "RSA (local) + EAP-TLS (remote)"?!

Gruß,
Dani

Mit ner PfSense geht es über EAP-TLS einwandfrei mit Certificate only.

Das wäre ja mal sehr spannend... Das teste ich gleich mal aus!!

Beide benutzen ja eine Strongswan VICI im Hintergrund. Müsste man glatt mal checken was die pfSense da dann anders konfiguriert sollte das stimmen. Ich check das mal hab hier 2 Kisten mit der latest und greatest laufen.

Mhhh das würde mich auch Interessieren. Ich hab auf der PFSense auch nur RSA(local) + EAP TLS ( Remote ) laufen weil das andere Probleme gemacht hatte

Servus @all,
Windows kann via IKEv2 kein EAP-TLS für die Authentifizierung des VPN-Servers, hier steht in Windows für IKEv2 nur die reine PublicKey-Methode zur Verfügung. Deswegen muss hier in der OPNSense/pfSense auch zwingend die Methode RSA + EAP-TLS gewählt werden wenn man sich mittels Windows und Client-Zertifikaten ausweisen möchte!

Man sieht das auch hier in der von Strongswan bereitgestellten Strongswan-Config:
strongSwan Configuration for Windows User Certificates
Ein testweise eingesetztes auth = eap-tls in der local config führt dann ganz klar zu einer not supported Meldung des Windows-Clients in der IKE Message auf dem Server.

"Beidseitige" EAP-TLS Auth funktioniert also definitiv nicht mit Windows-Clients, wer was anderes behauptet, lügt, zumindest zur Zeit

.

Die CRLs müssen natürlich korrekt hinterlegt sein und der Strongswan diese auch aktualisieren. Dann klappt auch das Widerrufen der Zertifikate in diesem Modus. Wie die OPNSense das handhabt muss ich mir mal ansehen, offensichtlich nicht konsistent wenn diese die Einwahl trotz aktueller CRL zulässt.
In Strongswan gibt es dazu die Section authorities. Beispielhafte Config einer CA sieht so aus

authorities {
	myca {
		cacert = my_ca.pem
		crl_uris = "http://domain.de/mycrl.pem"  
	}
}

Dann klappt auch das Revoking, ein Beispiel des Trace-Outputs von Strongswan:

Und Windows verweigert die Anmeldung dann natürlich auch

Für Realtime Checking für zurückgezogene Certs würde ich aber zu OSCP greifen das prüft auf zurück gezogene Certs bei jedem IKE-Auth Vorgang. Im Gegensatz zu CRLs die erst kurz vor dem Gültigkeits-Ablauf der Liste aktualisiert werden. Hier müsste man dann die Ablaufzeit bspw. auf 1-2 Tage stellen oder manuell den Cache aktualisieren damit das vernünftig läuft.

Grüße Uwe

Die Selbsthilfegruppe wächst... Hallo Uwe.

Windows kann via IKEv2 kein EAP-TLS für die Authentifizierung des VPN-Servers, hier steht in Windows für IKEv2 nur die reine PublicKey-Methode zur Verfügung.

Hm... Kollege @5175293307 hat im Verlauf der Frage geschrieben/bestätigt, dass es bei ihm in Verbindung mit pfSense und Windwos funktioniert (Mobile Clients mit Client Certificate authentifizieren)

Ein testweise eingesetztes auth = eap-tls in der local config führt dann ganz klar zu einer not supported Meldung des Windows-Clients in der IKE Message auf dem Server.

Diese Meldung im Logfile der OPNsense ist in diesen Fall korrekt.

Wie die OPNSense das handhabt muss ich mir mal ansehen, offensichtlich nicht konsistent wenn diese die Einwahl trotz aktueller CRL zulässt.

Ich konnte weder im Client- und noch Server-Zertifikat etwas zu Sperrlisten finden. In der Weboberfläche unter System: Trust: Revocation gibt es entsprechende Einträge für die CA. Ich habe dort sogar manuell eine CRL angelegt, bevor ich die Zertifikate für den IPSec-Server und Client ausgestellt habe. Evtl. bin ich inzwischen durch suchen, testen betriebsblind geworden.

In Strongswan gibt es dazu die Section authorities. Beispielhafte Config einer CA sieht so aus

Hast du die Konfiguration jetzt auf einer pfSense, OPNsense oder einfach unter einem Linux deiner Wahl durchgeführt?

Gruß,
Dani

Moin,
es wird immer besser:
IPSec Certification Revocation List
Revocation ohne Neustart

Gruß,
Dani

Zitat von @Dani:
Hm... Kollege @5175293307 hat im Verlauf der Frage geschrieben/bestätigt, dass es bei ihm in Verbindung mit pfSense und Windwos funktioniert

Kann definitiv nicht sein, da muss er die Methoden verwechselt haben, es geht Prinzipbedingt nicht. Da habe ich vor einiger Zeit schon mal nachgeforscht und und bin tief in die IKEv2 Windows Interna eingestiegen deswegen bin ich mir da 100% sicher.

Diese Meldung im Logfile der OPNsense ist in diesen Fall korrekt.

Richtig.

Muss ich mir die Tage mal auf der OPNSense ansehen was da über die GUI geht, über die Strongswan-Config geht es auf jeden Fall, Frage ist ob die GUI weitere Anpassungen diesbezüglich zulässt, ansonsten bleibt nur Tweaking auf der Konsole. Heute aber keine Zeit mehr.

In Strongswan gibt es dazu die Section authorities. Beispielhafte Config einer CA sieht so aus

Hast du die Konfiguration jetzt auf einer pfSense, OPNsense oder einfach unter einem Linux deiner Wahl durchgeführt?

Das war jetzt nur ein Beispiel auf einem plain vanilla Archlinux mit Strongswan.

Da muss ich mich tatsächlich korrigieren, sorry. @colinardo hat Recht, ich hatte da etwas in falscher Erinnerung.

Also, habe mir das mit CRLs und OCSP auf der OPNSense mal angeschaut. Folgende Punkte sind mir aufgefallen

Ein Plugin für OCSP gibt es (noch) nicht, einfaches Konfigurieren fällt also erst mal flach
Habe dann mal per OpenSSL erfolgreich eine OCSP Instanz auf Port 8080 über die Konsole der OPNSense gestartet, das klappt schon mal. Dann zusätzlich unter "/usr/local/etc/swanctl/conf.d/" eine *.conf Datei mit der URL der gerade gestarteten OCSP Instanz hinterlegt und mit swanctl -b in die aktuelle running config geladen, auch das war erfolgreich. Problem ist aber das die Strongswan-Version auf der OPNSense ohne "Fetcher (curl)" gebaut wurde, heißt dann im Klartext, strongswan kann die http URL für die OCSP-Validierunge nicht abrufen was sich auch im IPSec-Log zeigt:

2023-02-01T12:49:29	Informational	charon	11[CFG] <con2|3> certificate status is not available	
2023-02-01T12:49:29	Informational	charon	11[CFG] <con2|3> ocsp check failed, fallback to crl	
2023-02-01T12:49:29	Informational	charon	11[CFG] <con2|3> ocsp request to http://192.168.50.1:8080 failed	
2023-02-01T12:49:29	Informational	charon	11[LIB] <con2|3> unable to fetch from http://192.168.50.1:8080, no capable fetcher found	
2023-02-01T12:49:29	Informational	charon	11[CFG] <con2|3> requesting ocsp status from 'http://192.168.50.1:8080' ...	  
2023-02-01T12:49:29	Informational	charon	11[CFG] <con2|3> checking certificate status of "C=DE, ST=XXX, L=XXXX, O=private, E=userA@opnsense.tld, CN=userA"  

Könnte man zwar seine eigene strongswan bauen und einpflanzen, das ist aber für Otto-Normalo nicht so einfach zu bewerkstelligen.

Beleibt also CRL oder Radius.
Die in die GUI integrierte CRL-Verwaltung hinterlegt die CRLs leider nicht im Strongswan-Verzeichnis, so das diese dort nicht berücksichtigt werden.

Hier könnte man die CRL selbst generieren und nach /usr/local/etc/swanctl/x509crl auf die OPNSense kopieren und dann mittels Shell-Befehl swanctl -s aktualisieren lassen.
Danach sind die dort enthaltenen zurückgezogenen Zertifikate gesperrt.

Alles in allem doch noch eine ziemliche Bastelei auf der OPNSense. Ich würde hier auf einen Radius (z.B. Onboard Freeradius via Plugin) ausweichen dann entgeht man diesem Gebastel auf der OPNSense und der Radius übernimmt die Validierung der Zertifikate etc . und dieser kann die CRL die man im Webinterface anlegen kann auch nutzen

Hth

Grüße Uwe

Hier mal das IPSec Beispiel-Setup mit dem Freeradius Package auf der OPNSense

Ohne jetzt deine IPSec Settings zu wiederholen, also nur die Settings für die Umstellung auf Radius-Authentication mit Zertifikaten über EAP-TLS.

Freeradius Plugin (os-freeradius) installieren

Freeradius aktivieren

Radius Client anlegen (localhost)

EAP Settings setzen

Radius Authentication Backend erstellen

IPSec Phase 1 Settings auf Radius Authentication Backend umstellen

Der Rest von den IPSec-Settings kann gleich bleiben.

Man beachte den wichtigen Hinweis wenn man die CRL aktualisiert hat (also ein neues Zertifikat revoked hat)

Connection Log eines Windows Clients bestätigt die Radius Übergabe der Authentifizierung

Freeradius Log wenn man ein Zertifikat zurückzieht

IPSec Log wenn man ein Zertifikat zurückzieht

Windows Client nach dem zurückziehen des Zertifikates / wie erwartet ist er nun nicht mehr in der Lage sich zu verbinden

Danke Uwe! 👏👍 Mehr Silbertablett geht ja nicht für eine Lösung. Da ist das Wochenende mit Testen dann gesichert... 😉
Ich werde den Link mal ins pfSense/OPNsense VPN Tutorial übernehmen.

Moin Uwe,
vielen lieben Dank!

Probiere ich am Weekend in Ruhe aus. Vermutlich wird es schneller gehen als gedacht und somit hab ich Zeit im Überfluss.

Gruß,
Dani

Da hab ich euch beiden ja wieder "Wochenend-Arbeit" aufgehalst 😜, hoffentlich beschweren sich eure besseren Hälften nicht

, viel Erfolg/Spaß dabei.

Guten Abend Uwe,
ich hab dich nicht vergessen... aber wie so oft, sind ein paar Dinge dazwischen gekommen.

Was soll ich großartig schreiben, es läuft wie du es beschrieben hast. Ich hab mich allerdings für eine 2 Tier PKI entschieden. Aber das sind Details...

Gruß,
Dani