alex156
Goto Top

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.

Content-ID: 2573063142

Url: https://administrator.de/forum/ikev2-vpn-ungueltiger-zertifikattyp-2573063142.html

Ausgedruckt am: 22.12.2024 um 23:12 Uhr

aqui
aqui 22.04.2022 um 22:12:06 Uhr
Goto Top
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
lcer00
lcer00 23.04.2022 um 08:12:28 Uhr
Goto Top
Hallo,

Was sagt denn das eventlog des Servers? Gibt es da eine spezifischere Fehlermeldung?

Grüße

lcer
alex156
alex156 23.04.2022 um 19:06:25 Uhr
Goto Top
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?
lcer00
lcer00 23.04.2022 um 21:39:28 Uhr
Goto Top
clSchak
clSchak 25.04.2022 um 12:18:08 Uhr
Goto Top
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
alex156
alex156 25.04.2022 um 12:33:39 Uhr
Goto Top
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.
clSchak
clSchak 25.04.2022 um 12:40:11 Uhr
Goto Top
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:

admin2
aqui
aqui 25.04.2022 um 12:53:24 Uhr
Goto Top
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.
alex156
alex156 25.04.2022 um 21:24:34 Uhr
Goto Top
Hallo,

habe soeben das Zertifikat geändert.
am Client:
unbenannt

Zertifizeriungsstelle und RAS neu gestartet
alle Zertifikate neu ausgestellt und verteilt.

wieder das gleiche: "ungültiger Zertifikattyp"
aqui
aqui 26.04.2022 um 08:29:04 Uhr
Goto Top
Ein kleiner Raspberry Pi für 10 Euro kann das besser. face-wink
alex156
alex156 26.04.2022 um 09:11:20 Uhr
Goto Top
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:

unbenannt

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....
colinardo
Lösung colinardo 26.04.2022 aktualisiert um 12:08:44 Uhr
Goto Top
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).

  1. Always On VPN – Certificates and Active Directory
  2. Always On VPN – VPN and NPS Server Configuration
  3. 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
aqui
aqui 27.06.2022 um 15:12:56 Uhr
Goto Top
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!