Abhilfe: SSTP VPN-Verbindung funktioniert nicht mehr

In einem vorherigen Artikel habe ich bereits die etwas komplexe Einrichtung eines SSTP VPN-Netzwerks unter Windows Server 2008/2012 beschrieben. Nicht wirklich einfacher gestaltet sich dann auch die Fehlersuche ohne konkrete Vorkenntnisse, wenn das VPN auf einem Client wie aus heiterem Himmel plötzlich nicht mehr funktioniert.

Dieser Artikel soll aufzeigen, wie sich die meisten Fehler bei einer SSTP VPN-Verbindung schnell beheben lassen.

Zertifikate

Bei einer SSTP-Verbindung spielen Zertifikate eine wichtige Rolle. Konkret gibt es bei einem eingerichteten SSTP zwei verschiedene Zertifikate:

  • CA-Zertifikat (CAC): Dieses weißt den VPN-Server als „Vertrauenswürdige Zertifizierungsstelle“ aus. Es muss sowohl auf dem Server selbst als auch bei jedem Client im Zertifikatsspeicher unter Vertrauenswürdige Stammzertifizierungsstellen hinterlegt sein. Clients können es sich auch unterwegs über den Server herunterladen (z.B. https://myserver.dyndns.org/certsrv, siehe HowTo).
  • SSL-Zertifikat: Dieses sichert die HTTPS-Verbindung zwischen Client und Server und muss im Server sowohl im Routing und RAS- als auch im IIS-Dienst hinterlegt werden. Das SSL-Zertifikat muss auf die Domain ausgestellt sein, über die der Server über das Internet zu erreichen ist (z.B. myserver.dyndns.org).

Beide Zertifikate lassen sich auf dem Server einsehen. Man geht im Server-Manager auf Rollen > Webserver (IIS) > Internetinformationsdienste, in der zweiten Baumansicht auf den eigenen Server und in der rechten Liste dann ziemlich weit unten auf Serverzertifikate. Hier sollten nun beide Zertifikate auftauchen. Durch einen Doppelklick kann man alle Details zum Zertifikat einsehen, z.B. den Fingerabdruck unter Details, Anzeigen: Nur Eigenschaften.

Allgemeine Fehlersuche

Ganz gleich, welcher Fehler beim Versuch einer SSTP VPN-Verbindung auftritt, arbeitet man am besten systematisch folgende Schritte ab.

  1. CA-Zertifikat auf dem Client prüfen.
    1. Start > Ausführen, mmc eingeben und bestätigen.
    2. Datei > Snap-In hinzufügen/entfernen…, linke Liste herunterscrollen, Doppelklick auf Zertifikate. Option Computerkonto auswählen, Weiter, Fertig stellen.
    3. In der Baumansicht unter Zertifikate (Lokaler Computer) > Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate sollte ziemlich weit unten das korrekte Server CA-Zertifikat auftauchen (Ablaufdatum und Fingerabdruck überprüfen). Falls nicht, die Client-Einrichtung im HowTo wiederholen.
  2. Erreichbarkeit des Servers prüfen.
    1. Auf einem Client die IIS-Seite des Servers über HTTP und HTTPS aufrufen (z.B. http://myserver.dyndns.org bzw. https://myserver.dyndns.org). Klappt das, weiter mit Schritt 2.
    2. Ansonsten prüfen, ob Port 80 und 443 im Router korrekt an den Server weitergeleitet wird.
    3. Auf dem Server selbst einen Browser öffnen und https://localhost aufrufen. Bei einem Verbindungsfehler hat der Server die SSL-Bindung verloren (möglicherweise ein Bug, siehe hier). In diesem Fall:
      1. Server-Manager > Rollen > Webserver (IIS) > Internetinformationsdienste
      2. In der zweiten Baumansicht unter dem eigenen Server auf Sites > Default Web Site, dann ganz rechts auf Bindungen…
      3. In der Liste den Eintrag https auswählen, Bearbeiten…
      4. Hier prüfen, ob unter SSL-Zertifikat das korrekte SSL-Zertifikat ausgewählt ist.
      5. Den Dialog mit OK (nicht Abbrechen!) schließen. Nun sollte der SSL-Zugang wieder funktionieren.
  3. CA-Zertifikat auf dem Server prüfen (Vorgehen analog zu Schritt 1).
  4. SSL-Zertifikate auf dem Server überprüfen
    1. Auf dem Server eine cmd öffnen
      1. netsh http show ssl
      2. Es sollten für die Ports 0.0.0.0:443 sowie [::]:443 jeweils das korrekte SSL-Zertifikat hinterlegt sein (Fingerabruck überprüfen).
      3. Falls nicht, folgendes durchführen (kann auch in eine BAT-Datei kopiert werden). Nicht vergessen, xxxxxx nach certhash= durch den Fingerabdruck des eigenen SSL-Zertifikats zu ersetzen.
        netsh http delete sslcert 0.0.0.0:443
        netsh http delete sslcert [::]:443
        reg delete HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA1CertificateHash /f
        reg delete HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /f
        netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxxxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY
        netsh http add sslcert ipport=[::]:443 certhash=xxxxxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY
        net stop sstpsvc /y
        net start remoteaccess
      4. Ein netsh http show ssl sollte nun das korrekte SSL-Zertifikat zeigen.  Jetzt mit den beiden nächsten Unterschritten fortfahren.
    2. Im Server-Manager unter Rollen > Netzwerkrichtlinien- und Zugriffsdienste Rechtsklick auf Routing und RAS, dann Eigenschaften > Sicherheit. Unter SSL-Zertifikatbindung muss das korrekte SSL-Zertifikat ausgewählt sein. OK.
    3. SSL-Zertifikat des IIS-Dienstens wie in Schritt 2C) prüfen.
  5. Prüfen, ob der Port 443 am Server korrekt abgehört wird.
    1. In einer cmd den Befehl netstat -ano ausführen.
    2. Es sollten drei Einträge mit dem Port 443 existieren, alle mit der gleichen Prozess-ID (PID) des Systemprozesses (siehe Taskmanager):
      1. Lokal 0.0.0.0:433 / Remote 0.0.0.0:0 / Status ABHÖREN
      2. Lokal <Server-IP>:433 / Remote <Internet-IP>:<irgendeine Portnummer> / Status WARTEND (Status HERGESTELLT bei bestehender SSTP-Verbindung)
      3. Lokal [::]:433 / Remote [::]:0 / Status ABHÖREN
    3. Sollten hier Unstimmigkeiten bestehen, stört evtl. eine andere Anwendung.

Spätestens nach dem letzten Schritt sollte die SSTP-Verbindung wieder ohne Fehler laufen.

Häufige SSTP Verbindungsfehler

Fehler 0x800B0109: Eine Zertifikatkette wurde zwar verarbeitet, endete jedoch mit einem Stammzertifikat, das beim Vertrauensanbieter nicht als vertrauenswürdig gilt.

CA-Zertifikat ist auf dem Client nicht korrekt hinterlegt. Siehe oben unter Schritt 1).

Fehler 0x80072746: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
Fehler 0x800B010F: Der CN-Name des Zertifikats stimmt nicht mit dem übergebenen Wert überein.

Auf dem Server ist das SSL-Zertifikat nicht korrekt eingebunden oder abgelaufen. Oben ab Schritt 2) prüfen.

Fehler 0x8007274C: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat.

Der Server ist wahrscheinlich nicht per SSL erreichbar. Siehe oben unter Schritt 2).

Fehler 0x080092013: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

Der Sperrlisten-Verteilungspunkt im SSL-Zertifikat des Servers ist nicht korrekt eingetragen oder nicht erreichbar.
Im Server-Manager unter Rollen > Webserver (IIS) > Internetinformationsdienste > [Eigener Server] Doppelklick in der Liste auf Serverzertifikate und dann auf das SSL-Zertifikat. Unter Details in der Liste auf Sperrlisten-Verteilungspunkte klicken. Im unteren Feld sollte dann ein Eintrag URL=http://myserver.dyndns.org/CertEnroll/... auftauchen (wenn der Eintrag nicht vorhanden oder nicht korrekt ist, sollte man die Einrichtung des Servers im HowTo ab Schritt 2) nochmals durchgehen). Es ist zu prüfen, ob diese Adresse auch von außerhalb erreichbar ist und im Router eine Portweiterleitung für Port 80 an den Server erfolgt.

Fehler 0x800B0101: Ein erforderliches Zertifikat befindet sich nicht im Gültigkeitszeitraum gemessen an der aktuellen Systemzeit oder dem Zeitstempel in der signierten Datei.

Das SSL-Zertifikat auf dem Server ist abgelaufen. Dieses läuft i.d.R. nach einem Jahr ab und muss dann verlängert werden.
Dazu im Server-Manager unter Rollen > Webserver (IIS) > Internetinformationsdienste > [Eigener Server] Doppelklick in der Liste auf Serverzertifikate. Hier prüfen, ob das SSL-Zertifikat noch gültig ist. Dieses lässt sich dann per Rechtsklick verlängern. Das Ausstellen eines neuen Zertifikates ist im HowTo unter Schritt 3 bis 5 beschrieben.

Abschließende Bemerkungen

Solltet ihr einen Fehler erhalten, der oben nicht beschrieben ist, oder die Lösungsschritte nicht weiterhelfen, schreibt doch bitte in die Kommentare. Ansonsten freue ich mich natürlich wie immer über Lob und Kritik!

Weiterführende Links

Advertisements

15 Gedanken zu „Abhilfe: SSTP VPN-Verbindung funktioniert nicht mehr

  1. Hallo und danke für dieses 2do ….

    Habe auch folgendes Problem bei Aufbau einer Verbindung via SSTP gehabt, alle Protokolle gültig und Serverseitig richtig installiert — trotzdem war ….

    ————————————————————————————————————————–
    Fehler 0x800B010F: Der CN-Name des Zertifikats stimmt nicht mit dem übergebenen Wert überein.
    ————————————————————————————————————————–

    Die Lösung war ganz einfach, mann muss nur drauf kommen. Im Client habe ich, man hat ja eine feste Adresse am Server, die feste IP zur Einwahl angegeben …. Schnöde Angewohnheit — auf die ist aber das Zertifikat nicht ausgestellt – sondern auf den Domainnamen. Ganz schnell die feste IP gegen den Domainnamen getauscht …. Klasse wenn ein Plan funktioniert ….

    Grüsse

  2. Es gibt noch einen wichtigen Sonderfall. Und zwar wenn der IIS-Server ein anderes Zertifikat nutzt als für die VPN-Verbindung angegeben ist. Beispielsweise dann, wenn man ein LetsEncrypt-Zertifikat für den IIS-Server nutzt, um von gängigen Browsern als sicher eingestuft zu werden, aber für seinen VPN-Server ein eigenes Zertifikat nutzt (ausgestelt durch den CA des Servers).

    In diesem Fall wird die Verbindung bei Windows 10 aufgebaut (und im Server protokolliert), aber sofort wieder (scheinbar ohne Fehler) getrennt. In der Ereignisanzeige des Clients unter ServerRoles->Administrative Ereignisse findet sich dann der Fehler: „Die SSTP-basierte VPN-Verbindung mit dem RAS-Server wurde aufgrund eines Fehlers bei der Sicherheitsprüfung beendet. Die Sicherheitseinstellungen auf dem RAS-Server entsprechen nicht den Einstellungen auf dem Computer.“

    Eine funktionierende Lösung wäre natürlich das IIS-Zertifikat zu ändern. Es gibt aber ein Artikel von Microsoft der beschreibt, wie man mit verschiedenen Zertifikaten IIS- und RAS-Server betreiben kann (Link: https://support.microsoft.com/de-de/kb/947026). Außerdem gibt es dazu noch etwas hier: http://serverfault.com/questions/411656/sstp-client-disconnects-shortly-after-successfully-connected-to-vpn.

  3. Hallo,
    ist zwar schon eine Weile her, seit dem letzten Eintrag, aber da ich hier noch keine Lösung gefunden habe, werde ich sie hier mal mitteilen. Vielleicht hilft sie ja noch jemanden.
    Also erstmal ein Lob für die super Anleitung. Habe mich genauestens daran gehalten und es hat fast alles funktioniert. Ich erhielt auch die Fehlermeldung:
    Fehler 0x080092013: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.
    Nach einigem Suchen bin ich dann auch auf die Lösung gekommen. Die Sperrliste wird über http abgerufen, also Port 80. Der ist aber noch gar nicht im Router auf den Server weitergeleitet worden. Also eine HTTP-Portweiterleitung auf den Server für Port 80 im Router eingerichtet und der Fehler war weg. Die Verbindung funktionierte dann sofort.

    Hoffe ich konnte noch irgendjemanden helfen

    Viele Grüße

    Mike

  4. Danke für Deine tollen Anleitungen. Leider bekomme ich das VPN nicht zum laufen. Ein Port-Scan und „netstat -ano“ zeigen mit zwar 2 von 3 Ports 443 korrekt an, aber der mit der lokalen IP (192.168.x.xx) ist nicht mit einem Port 443 vertreten.
    Wir haben alle Schritte aus der Instal-Anleitung und aus der Fehlerbehebungsanleitung zweimal durch gearbeitet / repliziert.
    Wo könnte der Fehler liegen

      • Bei https://XXX.dyndns.org auf einem (fernen) Client sendet Chrome „ERR_CONNECTION_TIMED_OUT“
        Bei https://localhost auf dem Server sendet Chrome „NET::ERR_CERT_COMMON_NAME_INVALID“

        Im Detail sagt er dann:
        „Dieser Server konnte nicht beweisen, dass er localhost ist. Sein Sicherheitszertifikat stammt von XXX.dyndns.org (die DynDNS – DNS die im „Gemeinsamer Name“-Feld bei der Zertifikatserstellung eingetragen wurde {lt. Deiner Anleitung]).

        Ich bin nach Deiner Anleitung Schritt für Schritt vor gegangen und habe das ganze drei mal revidiert.

      • Der IIS ist wohl nicht korrekt für https konfiguriert. Ist im Servermanager im IIS die „Default Web Site“ für https korrekt an Port 443 gebunden (Rechtsklick > Bindungen bearbeiten)?

      • HTTPS mit Port 443 ist korrekt eingebunden. Habe die Bindung gelöscht und neu angelegt. Bei IP-Adresse steht die vom Server drinn (habe allerding auch „*“ probiert. Das bringt allerdings auch nichts.

    • Hallo Christoph Wander,
      ich weiß, dass es schon etwas her ist, aber hast du eine Lösung gefunden? Ich hab genau das gleiche Problem, dass der Port 443 bei der lokalen Ip-Adresse icht angezeigt wird, aber bei den anderen beiden schon 😦

      Mit besten Grüßen

      • Hallo,
        es hat jetzt bei mir doch geklappt! Deshalb möchte ich die kleine Ergänzung hinzufügen, was bei mir geholfen hat:

        Ausführen/Regedit/HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters

        habe ich noch den 32 Bit REG_DWord eingefügt mit den Namen „NoCertRevocationCert“ und den Wert auf 1 gesetzt. Das war die Lösung bei mir =)

        Das muss bei der Konfiguration des Clients ergänzt werden.

  5. Vielen Dank für Deine klasse Anleitungen. Leider stehe ich an einem Punkt, andem ich nicht weiter weiß und hoffe auf Deinen Rat.

    Obwohl ich die CRL einwandfrei über den im Zertifikat eingetragenen Sperrlistenverteilungspunkt (externer DDNS Adresse) erreichen und heruntergeladen kann, erhalte ich die Meldung: „Fehler 0x080092013: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.“

    Es existiert eine Unternehmens Root-CA und eine dazugehörige Sub-CA. Die SubCA hat das Zertifkat für den „Routing und RAS“ Server zur Verwendung von SSTP ausgestellt. Die SubCA befindet sich auf dem Routing und RAS Server. Das Zertifkat ist Im IIS des VPN, in der MMC (Zertifikate Computerkonto), sowie im Sicherheits Tab des Routing und RAS Servers zu finden.

    Der Domänen Client im Internet verbindete sich gestern noch mit dem Server ohne Probleme. Auch ein weiterer Client (non domain-member) hat sich gestern noch verbidnen können.

    Woran habe ich noch nicht gedacht?

    Danke
    Michael

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s