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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2573063142
Url: https://administrator.de/forum/ikev2-vpn-ungueltiger-zertifikattyp-2573063142.html
Ausgedruckt am: 22.12.2024 um 23:12 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,
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
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.
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
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!