SSTP en IKEv2 gebruiken verschillende RRAS-certificaatinstellingen

Vervangt u «het VPN-certificaat», dan wijzigt u mogelijk de verkeerde service. RRAS kent minstens drie certificaatinstellingen, elk behorend bij een ander protocol en een andere verbindingsrol. Het protocol eerst benoemen maakt van een riskante gok één enkele, omkeerbare bindingswijziging. Alles hieronder hangt van die ene zin af.

Benoem het protocol vóór het certificaat

Een SSTP-listener presenteert een TLS-certificaat aan een client die zich als HTTPS gedraagt. Een inkomende site-to-site-IKEv2-verbinding adverteert een serveridentiteit en valideert peercertificaten tegen een vertrouwde root. Een site-to-site-definitie per interface draagt een eigen machine-identiteit.

Dat zijn drie instellingen met drie bereiken. Ze verwarren levert een wijziging op die op het ene protocol lijkt te werken en op het andere geen effect heeft, wat erger is dan een duidelijke fout. Noteer welk protocol faalde, welke kant het certificaat presenteerde en welke kant het weigerde voordat u iets aanraakt.

SSTP is een HTTPS-binding

Voor ondersteunde Remote Access-implementaties biedt Set-RemoteAccess een parameter SslCertificate die wordt gebruikt voor SSTP-connectiviteit en voor de HTTPS-gerelateerde DirectAccess-rol.

Het bereik van validatie en implementatie volgt de Remote Access-configuratie, zodat één bindingswijziging meer dan één verbinding of knooppunt kan bereiken. In een load-balanced implementatie omvat dat bereik elk knooppunt dat de configuratie dekt. Eén knooppunt wijzigen en één client testen laat de rest het oude bladcertificaat presenteren, en dat is het soort halve wijziging dat een onderhoudsvenster overleeft.

Controleer vóór de update de verwachte servicenaam, de keten, de geldigheid, het beoogde gebruik en de beschikbaarheid van de privésleutel. Het certificaat moet overeenkomen met de naam die de client controleert, en een adapterlabel is die naam niet.

Inkomende IKEv2 heeft een eigen parameter

Set-VpnAuthProtocol configureert inkomende site-to-site-IKEv2-authenticatie, en CertificateAdvertised levert een certificaat wanneer de tunnelauthenticatiemodus die gebruikt. Het is geen algemeen commando om willekeurig welk servercertificaat op de host te kiezen.

Houd twee objecten uit elkaar: het bladcertificaat dat de server als eigen identiteit presenteert, en de root die hij gebruikt om peercertificaten te accepteren. Welke uitgever u vertrouwt zegt niets over welk bladcertificaat de server presenteert.

De identiteit van een afzonderlijke site-to-site-interface wordt ingesteld via Set-VpnS2SInterface. Het is niet automatisch het SSTP-certificaat, zelfs niet als beide in dezelfde opslag op dezelfde machine staan.

Inspecteer eerst de kandidaat

Een gerichte weergave van de lokale machineopslag toont openbare metadata zonder iets privés te exporteren:

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

Die lijst is een uitgangspunt en geen geschiktheidstest. Inspecteer de SAN-vermeldingen, de uitgebreide sleutelgebruiken, de keten en de toegang van het serviceaccount tot de privésleutel voor het protocol dat u configureert.

Een certificaat dat voor een losstaande cloud-clientidentiteit is geïnstalleerd, is niet geschikt alleen omdat het in dezelfde opslag verschijnt. Zichtbaarheid is geen geschiktheid, en een vingerafdruk in een schermafbeelding bewijst niets over de vraag of het serviceaccount de sleutel kan lezen. Controleer die toegang expliciet, want een ontbrekende sleutelmachtiging faalt pas wanneer de service opnieuw start en het certificaat probeert te gebruiken.

Leg de huidige binding vast en bevestig dat u de host nog via een andere weg kunt bereiken voordat u die wijzigt. Het herstelpad hoort bij de wijziging, niet bij het incident dat volgt.

Vernieuwen is geen activering

Een certificaat opnieuw uitgeven is een andere actie dan het selecteren voor de actieve service. Het nieuwe bladcertificaat kan de beoogde DNS-identiteit behouden en toch een andere vingerafdruk dragen, dus niets wijst ernaar tot de binding wordt bijgewerkt. Vernieuwing wijzigt het object; activering wijzigt de verwijzing ernaar. Die twee verwarren is de reden waarom een correct vernieuwd certificaat wekenlang ongebruikt kan blijven.

Pas de ondersteunde wijziging toe in een geschikt venster, inclusief een eventuele gedocumenteerde herstart, en inspecteer het certificaat daarna vanuit een nieuwe verbinding van het beoogde protocol. Een gecachte clientsessie kan nog het oude bladcertificaat tonen en een correcte wijziging defect laten lijken.

Trek het vorige certificaat pas via het normale proces in nadat die controle slaagt. De Set-RemoteAccess-referentie documenteert het bereik van de SSL-parameter, inclusief het effect in load-balanced implementaties, en dat is het deel dat u vóór een bindingswijziging wilt lezen.