SSTP og IKEv2 bruger forskellige RRAS-certifikatkontroller

Erstatter du «VPN-certifikatet», ændrer du muligvis den forkerte tjeneste. RRAS har mindst tre certifikatkontroller, som hver hører til en forskellig protokol og en forskellig forbindelsesrolle. Når du navngiver protokollen først, bliver et risikabelt gæt til en enkelt, reversibel bindingsændring. Alt nedenfor afhænger af den ene sætning.

Navngiv protokollen før certifikatet

En SSTP-lytter præsenterer et TLS-certifikat for en klient, der opfører sig som HTTPS. En indgående site-to-site-IKEv2-forbindelse annoncerer en serveridentitet og validerer peer-certifikater mod en betroet rod. En site-to-site-definition pr. interface bærer sin egen maskinidentitet.

Det er tre kontroller med tre omfang. At forveksle dem giver en ændring, der ser ud til at virke på én protokol og ingen effekt har på den anden, hvilket er værre end en tydelig fejl. Notér, hvilken protokol der fejlede, hvilken side der præsenterede certifikatet, og hvilken side der afviste det, før du rører noget.

SSTP er en HTTPS-binding

For understøttede Remote Access-implementeringer eksponerer Set-RemoteAccess en parameter SslCertificate, der bruges til SSTP-forbindelse og til den HTTPS-relaterede DirectAccess-rolle.

Dens validerings- og implementeringsomfang følger Remote Access-konfigurationen, så én bindingsændring kan nå mere end én forbindelse eller node. I en load-balanced implementering omfatter dette omfang hver node, som konfigurationen dækker. At ændre én node og teste én klient efterlader resten med det gamle bladcertifikat, og det er den slags halve ændring, der overlever et vedligeholdelsesvindue.

Kontroller det forventede tjenestenavn, kæden, gyldigheden, det tilsigtede forbrug og privatnøglens tilgængelighed før opdateringen. Certifikatet skal matche det navn, klienten kontrollerer, og en adapteretikette er ikke det navn.

Indgående IKEv2 har sin egen parameter

Set-VpnAuthProtocol konfigurerer indgående site-to-site-IKEv2-godkendelse, og CertificateAdvertised leverer et certifikat, når tunnelgodkendelsestilstanden bruger dem. Det er ikke en generel kommando til at vælge et vilkårligt servercertifikat på værten.

Hold to objekter adskilt: det bladcertifikat, serveren præsenterer som sin egen identitet, og den rod, den bruger til at acceptere peer-certifikater. Valget af, hvilken udsteder du stoler på, siger intet om, hvilket bladcertifikat serveren præsenterer.

Identiteten for et enkelt site-to-site-interface indstilles via Set-VpnS2SInterface. Det er ikke automatisk SSTP-certifikatet, selv når begge ligger i samme lager på samme maskine.

Undersøg kandidaten først

En målrettet visning af den lokale maskines lager viser offentlige metadata uden at eksportere noget privat:

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

Den liste er et udgangspunkt og ikke en egnethedstest. Undersøg SAN-posterne, de udvidede nøgleanvendelser, kæden og tjenestekontoens adgang til privatnøglen for den protokol, du konfigurerer.

Et certifikat, der er installeret til en urelateret cloud-klientidentitet, er ikke egnet, blot fordi det vises i samme lager. Synlighed er ikke egnethed, og et fingeraftryk på et skærmbillede beviser intet om, hvorvidt tjenestekontoen kan læse nøglen. Kontroller den adgang udtrykkeligt, for en manglende nøgletilladelse fejler først, når tjenesten genstarter og forsøger at bruge certifikatet.

Registrer den aktuelle binding, og bekræft, at du stadig kan nå værten på en anden måde, før du ændrer den. Gendannelsesvejen hører til ændringen, ikke til den hændelse, der følger.

Fornyelse er ikke aktivering

At genudstede et certifikat er en anden handling end at vælge det til den kørende tjeneste. Det nye bladcertifikat kan beholde den tilsigtede DNS-identitet og stadig have et andet fingeraftryk, så intet peger på det, før bindingen opdateres. Fornyelse ændrer objektet; aktivering ændrer referencen til det. At forveksle de to er grunden til, at et korrekt fornyet certifikat kan ligge ubrugt i uger.

Anvend den understøttede ændring i et passende vindue, inklusive enhver dokumenteret genstart, og undersøg derefter certifikatet fra en ny forbindelse med den tilsigtede protokol. En cachet klientsession kan stadig vise det gamle bladcertifikat og få en korrekt ændring til at se brudt ud.

Udfas det forrige certifikat via den normale proces først, når den kontrol er bestået. Set-RemoteAccess-reference dokumenterer SSL-parameterens omfang, herunder dens effekt i load-balanced implementeringer, hvilket er den del, der er værd at læse før en bindingsændring.