13
IKEv2 VPN "ungültiger Zertifikattyp"
Ich versuche unter Windows Server 2022 einen IKEv2 VPN einzurichten, erhalte aber beim Anmeldeversuch am Client den Fehler "ungültiger Zertifikattyp"
parallel habe ich derzeit auch den PPTP VPN eingerichtet, dieser funktioniert einwandfrei (Anmeldung Domänenbenutzer und Zertifikat).
Ich bin folgendermaßen vorgegangen:
Ich habe für das IKEv2 in der Zertifizierungsstelle ein Zertifikat vom Typ "IP-Sicherheits-IKE, dazwischenliegend" angelegt.
Habe am Server in der Zertifizierungsstelle alle Zertifikate neu ausstellen lassen
Habe dieses Zertifikat dann als Computerzertifikat an den Client in der AD (verbunden lokal übers Netzwerk) verteilt.
nun habe ich am Client die alten Zertifikate gelöscht.
den Client vom lokalen Netzwerk getrennt und über einen Hotspot mit dem Internet verbunden.
die IKEV2 Verbindung am Client angelegt, den DNS Server geändert auf die Adresse die der Server bei VPN Verbindung hat.
Verbindung getestet -> Benutzeranmeldung poppt auf -> Domänenbenutzerdaten eingegeben
"Verbindung mit VPN-Server nicht möglich Ungültiger Zertifikattyp"
Meine Domäne existiert nur lokal, ich habe keine externe Zertifizierungsstelle und das AD bzw. der DNS existieren nur im Netzwerk sind von außen nur nach VPN Einwahl erreichbar, das sollte aber kein Problem sein, da eine öffentliche Domäne und Zertifizierungsstelle ja nur für DirectAccess erforderlich ist oder hab ich da was missverstanden?
Zusatzfrage:
Ist die PPTP Verbindung so wie ich sie nutze wirklich so unsicher? Es werden doch nur Daten unverschlüsselt übertragen die Benutzerdaten sind doch trotzdem verschlüsselt da ich keine unverschlüsselte Verbindung zulasse.
parallel habe ich derzeit auch den PPTP VPN eingerichtet, dieser funktioniert einwandfrei (Anmeldung Domänenbenutzer und Zertifikat).
Ich bin folgendermaßen vorgegangen:
Ich habe für das IKEv2 in der Zertifizierungsstelle ein Zertifikat vom Typ "IP-Sicherheits-IKE, dazwischenliegend" angelegt.
Habe am Server in der Zertifizierungsstelle alle Zertifikate neu ausstellen lassen
Habe dieses Zertifikat dann als Computerzertifikat an den Client in der AD (verbunden lokal übers Netzwerk) verteilt.
nun habe ich am Client die alten Zertifikate gelöscht.
den Client vom lokalen Netzwerk getrennt und über einen Hotspot mit dem Internet verbunden.
die IKEV2 Verbindung am Client angelegt, den DNS Server geändert auf die Adresse die der Server bei VPN Verbindung hat.
Verbindung getestet -> Benutzeranmeldung poppt auf -> Domänenbenutzerdaten eingegeben
"Verbindung mit VPN-Server nicht möglich Ungültiger Zertifikattyp"
Meine Domäne existiert nur lokal, ich habe keine externe Zertifizierungsstelle und das AD bzw. der DNS existieren nur im Netzwerk sind von außen nur nach VPN Einwahl erreichbar, das sollte aber kein Problem sein, da eine öffentliche Domäne und Zertifizierungsstelle ja nur für DirectAccess erforderlich ist oder hab ich da was missverstanden?
Zusatzfrage:
Ist die PPTP Verbindung so wie ich sie nutze wirklich so unsicher? Es werden doch nur Daten unverschlüsselt übertragen die Benutzerdaten sind doch trotzdem verschlüsselt da ich keine unverschlüsselte Verbindung zulasse.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2573063142
Url: https://administrator.de/contentid/2573063142
Ausgedruckt am: 08.11.2024 um 05:11 Uhr
13 Kommentare
Neuester Kommentar
Ist die PPTP Verbindung so wie ich sie nutze wirklich so unsicher?
Mach dir selber ein Bild:https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
PPTP Clients sind heute ausnahmslos aus allen aktuellen Betriebssystemen entfernt was ja eine deutliche Sprache spricht.
Was deine Zertifikatsproblematik anbetrifft helfen dir ggf. diese beiden IKEv2 Tutorials als Beispiel:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Hallo,
Was sagt denn das eventlog des Servers? Gibt es da eine spezifischere Fehlermeldung?
Grüße
lcer
Was sagt denn das eventlog des Servers? Gibt es da eine spezifischere Fehlermeldung?
Grüße
lcer
Am Server im Eventlog die selbe Meldung
RemoteAccess
EventID: 20255
unten der Zertifikatname des Client-Computer-Zertifikatis und der gleiche Fehlertext: "ungültiger Zertifikattyp"
ist "IP-Sicherheits-IKE, dazwischenliegend" das Richtige für die Verbindung?
RemoteAccess
EventID: 20255
unten der Zertifikatname des Client-Computer-Zertifikatis und der gleiche Fehlertext: "ungültiger Zertifikattyp"
ist "IP-Sicherheits-IKE, dazwischenliegend" das Richtige für die Verbindung?
Hallo,
schau mal da: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/ras ...
Grüße
lcer
schau mal da: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/ras ...
Grüße
lcer
Hi
welche VPN Technik genau? IKEv2 kannst du ja auch in Verbindung mit AlwaysON-VPN oder DirectAccess (abgekündigt) aufbauen.
Das Zertifikat muss auf jeden Fall die von dir genannte Funktion (IP-Sicherheits-IKE, dazwischenliegend) und Client-/Serverauthentifzierung haben, zu dem ist es hilfreich, wenn man eine eigene CA betreibt damit das ROOT Zertifkat auf die Clients verteilt werden kann und man sich so einiges an Aufwand spart bei der Erneuerung der Zertifikate.
Gruß
@clSchak
welche VPN Technik genau? IKEv2 kannst du ja auch in Verbindung mit AlwaysON-VPN oder DirectAccess (abgekündigt) aufbauen.
Das Zertifikat muss auf jeden Fall die von dir genannte Funktion (IP-Sicherheits-IKE, dazwischenliegend) und Client-/Serverauthentifzierung haben, zu dem ist es hilfreich, wenn man eine eigene CA betreibt damit das ROOT Zertifkat auf die Clients verteilt werden kann und man sich so einiges an Aufwand spart bei der Erneuerung der Zertifikate.
Gruß
@clSchak
Hi,
ich versuche es Client seitig rein mit IKEv2. ohne Irgendein zusätzliches Protokoll darüber.
Als Server läuft der RAS Server von Windows Server 2022 über den derzeit auch der PPTP Zugang läuft.
Zertifizierungsstelle ist am selben Server auch Windows Server 2022 eingerichtet, Zertifikate erstellen / aktualisieren / verteilen auf die Clients funktioniert einwandfrei.
Client/Serverauthentifizierung ist ein extra Zertifikat dass auch CLients bekommen die keinen VPN erhalten sollen (daher aufgeteilt)
Ich denke das Problem ist, dass ich in meiner lokalen Domäne die Zertifizierungsstelle habe und die Zertifikate alle [Domänenname]-CA eingetragen haben bzw. dies auch bei den Clients in trusted root steht.
Wie gesagt, ist die Domäne aber nur lokal, kann also aus dem Internet nicht namentlich aufgelöst werden.
Ich vermute hier das Problem da der DNS ja erst nach der VPN Einwahl erreichbar ist und somit das Zertifikat nicht geprüft werden kann?
Wo in der Zertifikatsvorlage ich die öffentlich erreichbare Domäne / IP eintragen muss damit ich dies testen kann habe ich noch nicht rausgefunden.
ich versuche es Client seitig rein mit IKEv2. ohne Irgendein zusätzliches Protokoll darüber.
Als Server läuft der RAS Server von Windows Server 2022 über den derzeit auch der PPTP Zugang läuft.
Zertifizierungsstelle ist am selben Server auch Windows Server 2022 eingerichtet, Zertifikate erstellen / aktualisieren / verteilen auf die Clients funktioniert einwandfrei.
Client/Serverauthentifizierung ist ein extra Zertifikat dass auch CLients bekommen die keinen VPN erhalten sollen (daher aufgeteilt)
Ich denke das Problem ist, dass ich in meiner lokalen Domäne die Zertifizierungsstelle habe und die Zertifikate alle [Domänenname]-CA eingetragen haben bzw. dies auch bei den Clients in trusted root steht.
Wie gesagt, ist die Domäne aber nur lokal, kann also aus dem Internet nicht namentlich aufgelöst werden.
Ich vermute hier das Problem da der DNS ja erst nach der VPN Einwahl erreichbar ist und somit das Zertifikat nicht geprüft werden kann?
Wo in der Zertifikatsvorlage ich die öffentlich erreichbare Domäne / IP eintragen muss damit ich dies testen kann habe ich noch nicht rausgefunden.
dein Zertifkat erfüllt aber den "Zweck" nicht, das sagt auch die Fehlermeldung, das hat nichts mit DNS zu tun, was ich meine ist die "Erweiterte Schlüsselverwendung" da muss mehr rein:
ich versuche es Client seitig rein mit IKEv2. ohne Irgendein zusätzliches Protokoll darüber.
Sowas gibt es bei IKEv2 auch gar nicht !Der Windows IKEv2 Client ist etwas pedantisch. Wie schon in den beiden oben zitierten Tutorials beschrieben, muss der Windows Client als SAN den Common Name enthalten und zwar als FQDN und einmal nur als Hostname. Andere IKEv2 Clients wie die unter MacOS, iOS oder Linux/Android sind da deutlich toleranter.
Kollege @clSchak hat also Recht das da sehr wahrscheinlich entsprechende Parameter im Server Zertifikat fehlen.
Hallo,
habe soeben das Zertifikat geändert.
am Client:
Zertifizeriungsstelle und RAS neu gestartet
alle Zertifikate neu ausgestellt und verteilt.
wieder das gleiche: "ungültiger Zertifikattyp"
habe soeben das Zertifikat geändert.
am Client:
Zertifizeriungsstelle und RAS neu gestartet
alle Zertifikate neu ausgestellt und verteilt.
wieder das gleiche: "ungültiger Zertifikattyp"
Ein kleiner Raspberry Pi für 10 Euro kann das besser. 
habe heute Morgen noch mal probiert, per L2TP/IPsec mit Zertifikat zu verbinden. Also die Zertifikate die ich gestern noch neu ausgestellt habe. Musste hierfür den bestehenden L2TP abdrehen (deshalb wollte ich ja eig. auch IKEV2 da es andere Ports verwendet)
Also am Testclient folgendes konfiguriert:
VPN verbindet sofort.... das Zertifikat passt also...
Ich weiß nicht warum Microsoft hier immer noch so umständlich ist und es auch keine wirklich hilfreiche Wiki zu den IKEv2 VPN gibt.
Als Notnagel wäre es also denkbar dass ich nun wirklich einen RaspberryPi nehme und mit OpenVPN den Netzwerk-VPN realisiere....
Also am Testclient folgendes konfiguriert:
VPN verbindet sofort.... das Zertifikat passt also...
Ich weiß nicht warum Microsoft hier immer noch so umständlich ist und es auch keine wirklich hilfreiche Wiki zu den IKEv2 VPN gibt.
Als Notnagel wäre es also denkbar dass ich nun wirklich einen RaspberryPi nehme und mit OpenVPN den Netzwerk-VPN realisiere....
Servus,
dein "Client-Zertifikat" ist noch fehlerhaft, das Client-Zertfikat sollte im SAN als UPN den UserPrincipalName des Users enthalten des weiteren ist die IKE-Extension im Client-Zertifikat nicht erforderlich hier reicht in den ExtendedKeyUsage die "Client-Authentifizierung" vollkommen aus! Diese ist nur für die Server-Seite erforderlich.
Halte dich beim Deployment exakt an folgende Schritte (automatisches Deployment via XML kannst du überspringen) dann kommt das sofort zum fliegen, habe das hier erst selbst erst vor kurzen wenn auch nicht mit einer Windows CA sondern testweise mal mit einer Offline CA (XCA) eingerichtet (hier sind dann noch weitere Schritte erforderlich um die CA dem NPS vertrauenswürdig zu machen).
Übrigens MS hat schöne Dokumentationen dazu dort findest du die Requirements für die (P)EAP Zertifikate (ist zwar nicht mehr ganz taufrisch, gilt aber nach wie vor im Grundsatz)
Certificate Requirements for PEAP and EAP
Grüße Uwe
dein "Client-Zertifikat" ist noch fehlerhaft, das Client-Zertfikat sollte im SAN als UPN den UserPrincipalName des Users enthalten des weiteren ist die IKE-Extension im Client-Zertifikat nicht erforderlich hier reicht in den ExtendedKeyUsage die "Client-Authentifizierung" vollkommen aus! Diese ist nur für die Server-Seite erforderlich.
Halte dich beim Deployment exakt an folgende Schritte (automatisches Deployment via XML kannst du überspringen) dann kommt das sofort zum fliegen, habe das hier erst selbst erst vor kurzen wenn auch nicht mit einer Windows CA sondern testweise mal mit einer Offline CA (XCA) eingerichtet (hier sind dann noch weitere Schritte erforderlich um die CA dem NPS vertrauenswürdig zu machen).
- Always On VPN – Certificates and Active Directory
- Always On VPN – VPN and NPS Server Configuration
- Always On VPN – User Tunnel
Übrigens MS hat schöne Dokumentationen dazu dort findest du die Requirements für die (P)EAP Zertifikate (ist zwar nicht mehr ganz taufrisch, gilt aber nach wie vor im Grundsatz)
Certificate Requirements for PEAP and EAP
Grüße Uwe
1
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
