Windows 10/11 - Build-in VPN mit Zertifikaten nutzen
Vor kurzem wurde an mich die Anforderung heran getragen, dass ein IKEv2 VPN, mit Windows 10/11 Boardmitteln, zu einer Fortigate gebaut werden sollte. Bei einer ersten Prüfung wurde weiterhin festgelegt, dass dieses VPN keinen Schlüssel, sondern Zertifikate nutzen sollte. Hier fingen mein Problem an. Ich habe mal wieder festgestellt, dass Windows irgendwie keine sinnvollen Logeinträge liefert, um Probleme oder Fehler eingrenzen zu können. Daher habe ich mich entschieden, dass ich die von mir gewonnen Erkenntnisse hier teile um hoffentlich jemand anderem ein wenig Zeit bei der Fehlersuche zu ersparen.
Was genau hat mich fast zum verzweifeln gebracht? Ich habe die grundsätzliche Funktionalität über Zertifikate relativ schnell hinbekommen und mit einem externen Client konnte das VPN auch problemlos aufgebaut werden aber über den eingebauten VPN Client von Windows bekam ich immer eine Fehlermeldung. Final war mein Problem, die mir nicht bekannten Anforderungen an das Zertifikat welches das VPN Gateway dem Windows PC präsentieren muss. Hier gibt es ein paar Besonderheiten auf die ich folgend eingehen möchte.
Ich möchte noch gar nicht auf den Ganzen Bau des VPN Konstrukt eingehen, daher folgen jetzt noch ein paar Voraussetzungen. Ihr habt euch für den Windows Client ein Computerzertifikat erstellt und könnt dem VPN Gateway auch die dazu gehörige CA übergeben. Weiterhin habt ihr auf dem VPN Gateway das VPN selber schon konfiguriert.
Fangen wir an…..
Wir erzeugen uns auf dem Windows Client eine neue VPN Verbindung. Wie nicht anders zu erwarten, könnt ihr über die GUI keine weiteren Einstellungen vornehmen. Daher müssen wir dies über die Powershell ausführen.
Wir öffnen uns also eine Powershell mit Administratorenrechten und geben folgenden Befehl ein.
Add-VpnConnection -Name "Dialup_cert" -ServerAddress "10.100.100.1" -TunnelType "IkeV2" -AuthenticationMethod "MachineCertificate" -EncryptionLevel "Optional" -AllUserConnection -SplitTunneling
Schauen wir uns den Befehl etwas genauer an. Wir erstellen uns eine VPN Connection mit einem Namen, einer Adresse des Ziels, mit der Art des Tunnels, mit der Angabe welche Authentifizierungsmethode wir verwenden wollen, ob wir eine Verschlüsselung voraussetzen, ob die Verbindung für alle User verfügbar sein soll und ob nur gewisse Ziele darüber erreichbar sind. Hier merkt euch schon mal das Attribut „ServerAddress“ auf das wir nachher nochmal näher eingehen.
Als nächstes müssen wir die noh weitere Werte für die VPN Verbindung setzen. Hier möchte ich auch nicht zu genau darauf eingehen, weil das sehr abhängig davon ist, welche Sicherheitsmaßnahmen ihr für diese Verbindung nutzen wollt.
Set-VpnConnectionIPsecConfiguration -ConnectionName "Dialup_cert" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup None -Force
Somit haben wir dem Windows schon mal beigebracht was es machen soll. Trotzdem hat es bei mir dann nicht geklappt und Windows meldete sich mit der Meldung „IKE-Authentifizierungsinformationen sind nicht akzeptabel“. Bei meinem Mitschnitt auf dem VPN Gateway konnte ich allerdings sehen, dass sowohl die Phase 1 als auch die Phase 2 erfolgreich ausgehandelt wurden. Es ging sogar soweit, dass das VPN Gateway einen aktiven Tunnel meldete aber Windows nicht. Durch den Hinweis eines Kollegen, Danke Mike :-), und meine Beobachtungen, wusste ich, dass es am VPN Gateway Zertifikat liegen muss. Mit diesem Wissen, bin ich auf die zwei Bestandteile gestoßen, auf die ich heute hinweisen möchte.
Windows prüft zwei Sachen am Zertifikat! Zum einen wird geprüft, ob das Attribut „ServerAddress“ den gleichen Wert besitzt wie ein Eintrag im Bereich „Alternativer Antragsstellername“ oder im Englischen „Subject Alternative Name“ (SAN). In meinem Fall handelt es sich um eine IP Adresse, also muss auch diese in dem Bereich vorgehalten werden. Hier ein Beispiel.
X509v3 Subject Alternative Name:
DNS:vpngw.laptop.vpn.priv, IP Address:10.100.100.1
Das zweite und schwierigere herauszufinden war, dass Windows für VPN Verbindungen auf eine zusätzliche Schlüsselnutzung besteht. Genauer gesagt geht es hier um die sogenannte „Extended Key Usage“ (EKU). Windwos erwartet von dem Zertifikat, dass es explizit für die Authentifizierung von Serververbindungen erstellt wurde.
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Diese beiden Sachen musste ich zusätzlich bei meinen normalen Zertifikaten, hier könnt ihr gerne nochmal meinen Artikel dazu anschauen – https://cedigger.net/eigene-ssl-zertifikate-erstellen/, mitgeben damit die Verbindung erfolgreich aufgebaut wird. Wie gesagt schaut euch einfach meinen Artikel mit den Zertifikaten an und fügt in die Konfigurationsdatei, für die Zertifikate, folgende Sachen mit ein.
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = vpngw.laptop.vpn.priv
IP.1 = 10.100.100.1