SSTP-Zertifikat stimmt nicht: der Name, den Ihr Server vorweisen muss

SSTP Client akzeptiert den Server erst, wenn die TLS-Validierung gelingt, und diese Prüfung vergleicht einen Namen, eine Kette und einen Zweck. Der Name stammt aus dem Verbindungsprofil, nicht aus der Adresse, die Sie zufällig anpingen können. Wenn eines der drei nicht passt, meldet der Client ein Zertifikatsproblem und erreicht nie die Anmeldeaufforderung.

Der Profilname entscheidet, was geprüft wird

SSTP führt TLS über TCP 443 aus, also verhält sich der Client wie jeder andere TLS-Client: Er nimmt den Hostnamen aus dem Profil, fordert diesen Namen an und vergleicht das Zertifikat damit. Tragen Sie eine IP-Adresse ins Profil ein, wird der Vergleich zu einem IP-Adressvergleich, den die meisten Serverzertifikate nicht erfüllen.

Ein Browsertest kann daher gelingen, während das VPN scheitert, weil der Browser einen anderen Namen verwendete als das Profil. Dieselbe Aufspaltung zeigt sich, wenn Split-Horizon-DNS den VPN-Hostnamen in eine interne Adresse auflöst, während der Browser eine öffentliche erreichte. Gleichen Sie zuerst das Profil mit dem dokumentierten Hostnamen ab und vergleichen Sie dann Zertifikate. Alles andere, was Sie vorher ändern, ist Raten.

Was das Serverzertifikat tragen muss

Moderne Clients gleichen gegen die Erweiterung für alternative Subjektnamen ab, daher muss der Hostname dort als DNS-Eintrag stehen. Ein Common Name allein reicht für heutige Validierungsstapel nicht, und ein Platzhalter deckt eine Bezeichnung ab statt jeder beliebigen Subdomain, die Sie erfinden. Drei Zertifikate zeigen die Grenze: der richtige Name mit dem falschen Zweck bestätigt die Identität und scheitert dann an der Zweckprüfung, der richtige Name und Zweck mit fehlendem Zwischenzertifikat scheitert an der Kette, und ein Name, der nur im Common Name steht, scheitert, bevor eines der beiden anderen zählt.

Das Zertifikat braucht außerdem den Zweck Serverauthentifizierung, den Wert für erweiterte Schlüsselverwendung aus Microsofts SSTP-Spezifikation, also serverAuth mit der Objektkennung 1.3.6.1.5.5.7.3.1. Schlüsselverwendung und eine gültige Kette vervollständigen den Satz. Ein Zertifikat, das auf dem Server liegt, für den richtigen Namen ausgestellt wurde, aber nur für die Clientauthentifizierung gilt, scheitert trotzdem.

Kette und Uhr vor den Anmeldedaten prüfen

Zeit- und Vertrauensfehler erzeugen dasselbe sichtbare Ergebnis wie eine Namensabweichung, und beides ist billiger zu diagnostizieren als ein Passwortproblem. Prüfen Sie die Uhr des Servers und die Uhr des Clients und lesen Sie dann die Kette so, wie der Client sie sieht:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Der erste Befehl gibt den Namen, das Gültigkeitsfenster und die alternativen Namen aus, mit denen der Client vergleichen wird. Der zweite meldet Verifizierungsfehler mit der vorgelegten Kette, und dort zeigt sich ein fehlendes Zwischenzertifikat. Unter Windows sagt Ihnen die Abfrage des Zeitdienstes, ob die Uhr korrigiert wird oder einfach abgedriftet ist.

Eine interne CA fügt eine weitere Bedingung hinzu: Der Client muss dieser CA vertrauen. Installieren Sie die Organisationswurzel über ihren freigegebenen Verteilungskanal, nicht von einer Seite, die ein Ersatzzertifikat anbietet, denn diese Entscheidung ist das gesamte Vertrauensmodell in klein.

Servervalidierung und Benutzerauthentifizierung sind aufeinanderfolgende Stufen mit unterschiedlichen Fehlern. Ein Zertifikatsfehler bedeutet, dass der Client dem Server nie vertraut hat, während ein abgelehntes Passwort bedeutet, dass er ihm vertraut hat und die Anmeldedaten falsch waren. Die Zertifikatsprüfung abzuschalten, um zur Passwortaufforderung zu gelangen, entfernt die Garantie, statt sie zu reparieren. Um zu beweisen, dass der Rest des Weges funktioniert, testen Sie denselben Hostnamen und Port von einem Client, der der Kette bereits vertraut, und lassen Sie das ausgerollte Profil unangetastet.

Namen oder Zertifikat korrigieren und erneut testen

Drei Bedingungen entscheiden über die Reparatur. Ist der Profilname falsch, korrigieren Sie das Profil oder fügen Sie den fehlenden Namen dem Zertifikat hinzu. Ist die Kette unvollständig, installieren Sie das Zwischenzertifikat auf dem Server. Ist der Zweck falsch, stellen Sie neu aus, statt daran herumzuflicken.

Nach der Änderung verbinden Sie sich mit dem unterstützten Client erneut und bestätigen, dass die Anmeldeaufforderung erscheint und dann der Tunnel hochkommt. Notieren Sie den verwendeten Hostnamen, den Aussteller und das Ablaufdatum im Ticket. Diese Aufzeichnung macht die nächste Erneuerung zu einer geplanten Aufgabe statt zu einem weiteren Ausfall, und sie zeigt der nächsten Person, welche der drei Bedingungen tatsächlich verletzt war.