SSTP och IKEv2 använder olika RRAS-certifikatkontroller

Byter du ut «VPN-certifikatet» kan du ändra fel tjänst. RRAS har minst tre certifikatkontroller, som var och en tillhör ett annat protokoll och en annan anslutningsroll. Att först namnge protokollet gör en riskabel gissning till en enda, reversibel bindningsändring. Allt nedan hänger på den enda meningen.

Namnge protokollet före certifikatet

En SSTP-lyssnare presenterar ett TLS-certifikat för en klient som beter sig som HTTPS. En inkommande site-to-site-IKEv2-anslutning annonserar en serveridentitet och validerar peer-certifikat mot en betrodd rot. En site-to-site-definition per gränssnitt bär en egen maskinidentitet.

Det är tre kontroller med tre omfång. Att blanda ihop dem ger en ändring som verkar fungera på ett protokoll och inte har någon effekt på det andra, vilket är värre än ett uppenbart fel. Anteckna vilket protokoll som misslyckades, vilken sida som presenterade certifikatet och vilken sida som avvisade det innan du rör något.

SSTP är en HTTPS-bindning

För Remote Access-distributioner som stöds exponerar Set-RemoteAccess en parameter SslCertificate som används för SSTP-anslutning och för den HTTPS-relaterade DirectAccess-rollen.

Dess validerings- och distributionsomfång följer Remote Access-konfigurationen, så en bindningsändring kan nå mer än en anslutning eller nod. I en lastbalanserad distribution omfattar det omfånget varje nod som konfigurationen täcker. Att ändra en nod och testa en klient lämnar resten med det gamla lövcertifikatet, och det är den typ av halv ändring som överlever ett underhållsfönster.

Verifiera det förväntade tjänstenamnet, kedjan, giltigheten, det avsedda användningsområdet och den privata nyckelns tillgänglighet före uppdateringen. Certifikatet måste matcha namnet som klienten kontrollerar, och en adapteretikett är inte det namnet.

Inkommande IKEv2 har en egen parameter

Set-VpnAuthProtocol konfigurerar inkommande site-to-site-IKEv2-autentisering, och CertificateAdvertised tillhandahåller ett certifikat när tunnelautentiseringsläget använder dem. Det är inte ett allmänt kommando för att välja vilket servercertifikat som helst på värden.

Håll två objekt åtskilda: det lövcertifikat som servern presenterar som sin egen identitet, och den rot den använder för att acceptera peer-certifikat. Vilken utgivare du litar på säger inget om vilket lövcertifikat servern presenterar.

Identiteten för ett enskilt site-to-site-gränssnitt anges via Set-VpnS2SInterface. Det är inte automatiskt SSTP-certifikatet, även när båda ligger i samma arkiv på samma dator.

Granska först kandidaten

En riktad vy av den lokala datorns arkiv visar offentliga metadata utan att exportera något privat:

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

Listningen är en utgångspunkt och inte ett lämplighetstest. Granska SAN-posterna, de utökade nyckelanvändningarna, kedjan och tjänstekontots åtkomst till den privata nyckeln för det protokoll du konfigurerar.

Ett certifikat som installerats för en orelaterad molnklientidentitet är inte lämpligt bara för att det visas i samma arkiv. Synlighet är inte lämplighet, och ett tumavtryck på en skärmbild bevisar inget om huruvida tjänstekontot kan läsa nyckeln. Kontrollera den åtkomsten uttryckligen, eftersom en saknad nyckelbehörighet misslyckas först när tjänsten startar om och försöker använda certifikatet.

Registrera den aktuella bindningen och bekräfta att du fortfarande kan nå värden på annat sätt innan du ändrar den. Återställningsvägen hör till ändringen, inte till incidenten som följer.

Förnyelse är inte aktivering

Att utfärda ett certifikat på nytt är en annan åtgärd än att välja det för den körande tjänsten. Det nya lövcertifikatet kan behålla den avsedda DNS-identiteten och ändå ha ett annat tumavtryck, så inget pekar på det förrän bindningen uppdateras. Förnyelse ändrar objektet; aktivering ändrar referensen till det. Att förväxla de två är anledningen till att ett korrekt förnyat certifikat kan ligga oanvänt i veckor.

Tillämpa den stödda ändringen i ett lämpligt fönster, inklusive eventuell dokumenterad omstart, och granska sedan certifikatet från en ny anslutning med det avsedda protokollet. En cachad klientsession kan fortfarande visa det gamla lövcertifikatet och få en korrekt ändring att se trasig ut.

Avveckla det tidigare certifikatet via den normala processen först efter att den kontrollen har godkänts. Set-RemoteAccess-referensen dokumenterar SSL-parameterns omfång, inklusive dess effekt i lastbalanserade distributioner, vilket är den del som är värd att läsa före en bindningsändring.