SSTP og IKEv2 bruker ulike RRAS-sertifikatstyringer

Erstatter du «VPN-sertifikatet», kan du komme til å endre feil tjeneste. RRAS har minst tre sertifikatstyringer, og hver av dem hører til en annen protokoll og en annen tilkoblingsrolle. Å navngi protokollen først gjør en risikabel gjetning om til én enkelt, reversibel bindingsendring. Alt nedenfor henger på den ene setningen.

Navngi protokollen før sertifikatet

En SSTP-lytter presenterer et TLS-sertifikat for en klient som oppfører seg som HTTPS. En innkommende site-to-site-IKEv2-forbindelse annonserer en serveridentitet og validerer peer-sertifikater mot en betrodd rot. En site-to-site-definisjon per grensesnitt bærer sin egen maskinidentitet.

Dette er tre styringer med tre omfang. Å forveksle dem gir en endring som ser ut til å virke på én protokoll og ikke har noen virkning på den andre, noe som er verre enn en åpenbar feil. Skriv ned hvilken protokoll som feilet, hvilken side som presenterte sertifikatet og hvilken side som avviste det, før du tar i noe.

SSTP er en HTTPS-binding

For støttede Remote Access-distribusjoner eksponerer Set-RemoteAccess en parameter SslCertificate som brukes for SSTP-tilkobling og for den HTTPS-relaterte DirectAccess-rollen.

Validerings- og distribusjonsomfanget følger Remote Access-konfigurasjonen, slik at én bindingsendring kan nå mer enn én tilkobling eller node. I en lastbalansert distribusjon omfatter dette omfanget hver node som konfigurasjonen dekker. Å endre én node og teste én klient lar resten presentere det gamle løvsertifikatet, og det er den typen halve endring som overlever et vedlikeholdsvindu.

Verifiser det forventede tjenestenavnet, kjeden, gyldigheten, tiltenkt bruk og tilgjengeligheten til den private nøkkelen før oppdateringen. Sertifikatet må samsvare med navnet klienten vil kontrollere, og en adapteretikett er ikke det navnet.

Innkommende IKEv2 har sin egen parameter

Set-VpnAuthProtocol konfigurerer innkommende site-to-site-IKEv2-autentisering, og CertificateAdvertised skaffer et sertifikat når tunnelautentiseringsmodusen bruker dem. Det er ikke en generell kommando for å velge hvilket som helst serversertifikat på verten.

Hold to objekter fra hverandre: løvsertifikatet serveren presenterer som sin egen identitet, og roten den bruker for å godta peer-sertifikater. Hvilken utsteder du stoler på sier ingenting om hvilket løvsertifikat serveren presenterer.

Identiteten til et enkelt site-to-site-grensesnitt settes via Set-VpnS2SInterface. Det er ikke automatisk SSTP-sertifikatet, selv når begge ligger i samme lager på samme maskin.

Inspiser kandidaten først

En fokusert visning av den lokale maskinens lager viser offentlige metadata uten å eksportere noe privat:

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

Denne listen er et utgangspunkt og ikke en egnethetstest. Inspiser SAN-oppføringene, de utvidede nøkkelbrukene, kjeden og tjenestekontoens tilgang til den private nøkkelen for protokollen du konfigurerer.

Et sertifikat installert for en urelatert skyklientidentitet er ikke egnet bare fordi det dukker opp i samme lager. Synlighet er ikke egnethet, og et fingeravtrykk i et skjermbilde beviser ingenting om hvorvidt tjenestekontoen kan lese nøkkelen. Kontroller den tilgangen eksplisitt, fordi en manglende nøkkeltillatelse først slår feil når tjenesten starter på nytt og prøver å bruke sertifikatet.

Noter den gjeldende bindingen og bekreft at du fortsatt kan nå verten på en annen måte før du endrer den. Gjenopprettingsveien hører til endringen, ikke til hendelsen som følger.

Fornyelse er ikke aktivering

Å utstede et sertifikat på nytt er en annen handling enn å velge det for den kjørende tjenesten. Det nye løvsertifikatet kan beholde den tiltenkte DNS-identiteten og likevel ha et annet fingeravtrykk, så ingenting peker på det før bindingen oppdateres. Fornyelse endrer objektet; aktivering endrer referansen til det. Å forveksle de to er grunnen til at et riktig fornyet sertifikat kan ligge ubrukt i ukevis.

Bruk den støttede endringen i et passende vindu, inkludert eventuell dokumentert omstart, og inspiser deretter sertifikatet fra en ny tilkobling med den tiltenkte protokollen. En bufret klientsesjon kan fortsatt vise det gamle løvsertifikatet og få en riktig endring til å se ødelagt ut.

Avvikle det forrige sertifikatet gjennom den normale prosessen først etter at den kontrollen er bestått. Set-RemoteAccess-referansen dokumenterer omfanget til SSL-parameteren, inkludert virkningen i lastbalanserte distribusjoner, og det er den delen som er verdt å lese før en bindingsendring.