SSTP und IKEv2 verwenden unterschiedliche RRAS-Zertifikatssteuerungen

Ersetzen Sie „das VPN-Zertifikat“, und Sie ändern möglicherweise den falschen Dienst. RRAS unterhält mindestens drei Zertifikatssteuerungen, die jeweils zu einem anderen Protokoll und einer anderen Verbindungsrolle gehören. Wenn Sie zuerst das Protokoll benennen, wird aus einer riskanten Vermutung eine einzelne, umkehrbare Bindungsänderung. Alles Folgende hängt von diesem einen Satz ab.

Benennen Sie das Protokoll vor dem Zertifikat

Ein SSTP-Listener präsentiert einem Client, der sich wie HTTPS verhält, ein TLS-Zertifikat. Eine eingehende Site-to-Site-IKEv2-Verbindung kündigt eine Serveridentität an und validiert Peer-Zertifikate gegen eine vertrauenswürdige Stammzertifizierungsstelle. Eine Site-to-Site-Definition pro Schnittstelle trägt eine eigene Maschinenidentität.

Das sind drei Steuerungen mit drei Geltungsbereichen. Wer sie verwechselt, erzeugt eine Änderung, die bei einem Protokoll zu funktionieren scheint und beim anderen wirkungslos bleibt, was schlimmer ist als ein offensichtlicher Fehler. Notieren Sie, welches Protokoll fehlgeschlagen ist, welche Seite das Zertifikat präsentiert hat und welche Seite es abgelehnt hat, bevor Sie etwas anfassen.

SSTP ist eine HTTPS-Bindung

Für unterstützte Remote Access-Bereitstellungen stellt Set-RemoteAccess einen Parameter SslCertificate bereit, der für SSTP-Konnektivität und für die HTTPS-bezogene DirectAccess-Rolle verwendet wird.

Sein Validierungs- und Bereitstellungsumfang folgt der Remote Access-Konfiguration, sodass eine Bindungsänderung mehr als eine Verbindung oder einen Knoten erreichen kann. In einer lastverteilten Bereitstellung umfasst dieser Umfang jeden Knoten, den die Konfiguration abdeckt. Einen Knoten zu ändern und einen Client zu testen lässt die übrigen das alte Blattzertifikat präsentieren, und das ist die Art von Halbänderung, die ein Wartungsfenster überlebt.

Prüfen Sie vor der Aktualisierung den erwarteten Dienstnamen, die Kette, die Gültigkeit, den beabsichtigten Verwendungszweck und die Verfügbarkeit des privaten Schlüssels. Das Zertifikat muss zu dem Namen passen, den der Client prüfen wird, und eine Adapterbezeichnung ist nicht dieser Name.

Eingehendes IKEv2 hat einen eigenen Parameter

Set-VpnAuthProtocol konfiguriert die eingehende Site-to-Site-IKEv2-Authentifizierung, und CertificateAdvertised liefert ein Zertifikat, wenn der Tunnelauthentifizierungsmodus diese verwendet. Es ist kein allgemeiner Befehl zum Auswählen eines beliebigen Serverzertifikats auf dem Host.

Halten Sie zwei Objekte auseinander: das Blattzertifikat, das der Server als eigene Identität präsentiert, und die Stammzertifizierungsstelle, die er verwendet, um Peer-Zertifikate zu akzeptieren. Die Wahl, welchem Aussteller Sie vertrauen, sagt nichts darüber aus, welches Blattzertifikat der Server präsentiert.

Die Identität einer einzelnen Site-to-Site-Schnittstelle wird über Set-VpnS2SInterface festgelegt. Sie ist nicht automatisch das SSTP-Zertifikat, selbst wenn beide im selben Speicher auf derselben Maschine liegen.

Prüfen Sie zuerst den Kandidaten

Eine gezielte Ansicht des lokalen Maschinenspeichers zeigt öffentliche Metadaten, ohne etwas Privates zu exportieren:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Diese Auflistung ist ein Ausgangspunkt und kein Eignungstest. Untersuchen Sie die SAN-Einträge, die erweiterten Schlüsselverwendungen, die Kette und den Zugriff des Dienstkontos auf den privaten Schlüssel für das Protokoll, das Sie konfigurieren.

Ein Zertifikat, das für eine unabhängige Cloud-Client-Identität installiert wurde, ist nicht schon deshalb geeignet, weil es im selben Speicher erscheint. Sichtbarkeit ist keine Berechtigung, und ein Fingerabdruck in einem Screenshot beweist nichts darüber, ob das Dienstkonto den Schlüssel lesen kann. Prüfen Sie diesen Zugriff ausdrücklich, denn eine fehlende Schlüsselberechtigung schlägt erst fehl, wenn der Dienst neu startet und das Zertifikat verwenden will.

Zeichnen Sie die aktuelle Bindung auf und bestätigen Sie, dass Sie den Host auf einem anderen Weg noch erreichen können, bevor Sie sie ändern. Der Wiederherstellungspfad gehört zur Änderung, nicht zum Vorfall, der folgt.

Erneuerung ist keine Aktivierung

Ein Zertifikat neu auszustellen ist eine andere Aktion als es für den laufenden Dienst auszuwählen. Das neue Blattzertifikat kann die beabsichtigte DNS-Identität behalten und dennoch einen anderen Fingerabdruck tragen, sodass nichts darauf zeigt, bis die Bindung aktualisiert wird. Die Erneuerung ändert das Objekt; die Aktivierung ändert den Verweis darauf. Wer beides verwechselt, ist der Grund, warum ein korrekt erneuertes Zertifikat wochenlang ungenutzt bleiben kann.

Wenden Sie die unterstützte Änderung in einem geeigneten Fenster an, einschließlich eines dokumentierten Neustarts, und prüfen Sie das Zertifikat dann über eine frische Verbindung des beabsichtigten Protokolls. Eine zwischengespeicherte Client-Sitzung kann noch das alte Blattzertifikat zeigen und eine korrekte Änderung defekt aussehen lassen.

Nehmen Sie das vorherige Zertifikat erst nach bestandener Prüfung über den normalen Prozess außer Betrieb. Die Set-RemoteAccess-Referenz dokumentiert den Geltungsbereich des SSL-Parameters, einschließlich seiner Wirkung in lastverteilten Bereitstellungen, also den Teil, den man vor einer Bindungsänderung lesen sollte.