Att återkalla en Azure Point-to-Site-klient innebär att lägga till dess fingeravtryck i gatewayens återkallade lista. Det innebär inte att radera den betrodda roten. Roten är utfärdaren för varje klientcertifikat du någonsin har delat ut, så att ta bort den är en annan åtgärd med mycket större påverkan. Återkallningens enhet är här ett enda certifikat.

Steg 1: Fastställ exakt vilket certifikat du menar

Börja vid certifikatposten, inte vid ett visningsnamn. Azure visar ett vänligt namn som du själv skrev, och den etiketten behöver inte matcha subjektet eller enheten som det utfärdades för.

Ytterligare en kontroll innan du återkallar: ta reda på hur många enheter som presenterar det. Om flera bärbara datorer byggdes från kopior av samma PFX låser återkallningen av fingeravtrycket ut alla, och Azure kan inte skilja den förlorade från reserven i lådan.

På klienten Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotAfter listar vad som är installerat för den användaren, och Cert:\LocalMachine\My är också värt att kontrollera eftersom VPN-klienten kan välja från vilket som helst av de två arkiven. Jämför fingeravtrycket med din registreringsinventering. Ett förnyat certifikat har ett annat fingeravtryck även när subjektet är identiskt.

Du behöver inte klientens privata nyckel eller en lösenordsskyddad PFX för att läsa fingeravtrycket för ett offentligt certifikat. Varje procedur som kräver en av dem är kopierad från en annan uppgift.

Steg 2: Lägg till det i gatewayens återkallade lista

Öppna gatewayen för det virtuella nätverket i portalen, sedan Point-to-site-konfigurationen och sedan avsnittet för återkallade certifikat. Lägg till ett vänligt namn som du känner igen om sex månader och klistra in fingeravtrycket som en enda sammanhängande sträng utan mellanslagen.

Kontrollera vilken gateway som är vald innan du sparar, för en prenumeration med flera gatewayer är just den plats där detta går fel. Microsofts vägledning för certifikatkonfiguration anger att certifikatet inte längre kan användas för att ansluta när uppdateringen har slutförts.

Bekräfta sedan det lagrade värdet i stället för att lita på portalens meddelande: az network vnet-gateway show --name gw-p2s --resource-group rg-vpn --query "vpnClientConfiguration.vpnClientRevokedCertificates" visar vad gatewayen faktiskt innehåller.

Steg 3: Verifiera båda riktningarna

Testa nekandet med det återkallade certifikatet och testa sedan att ett annat certifikat under samma rot fortfarande autentiseras. Det är det andra testet som folk hoppar över, och det är det som fångar en oavsiktlig borttagning av roten eller en policyändring som ingen nämnde. Använd en enhet där du kan se vilket certifikat som presenteras. En klient med flera certifikat kan tyst använda ett som fungerar och få din återkallning att se trasig ut.

Anteckna båda resultaten i ärendet. En återkallning som bara verifierats i nekanderiktningen är halvt verifierad.

Steg 4: Sessioner som redan är uppe

Det dokumenterade resultatet gäller nya anslutningar. Sträck inte ut det till ett löfte att varje befintlig tunnel faller i samma sekund som listan sparas. Om omedelbar borttagning är viktig, använd de kontroller som din utrullade konfiguration faktiskt erbjuder och kontrollera den specifika sessionen i stället för att anta.

Testa det separat från autentisering, eftersom de två misslyckas på olika ställen och lämnar olika spår.

Återställning och genvägarna du bör undvika

Återställning innebär att ta bort fingeravtrycket från den återkallade listan och vänta på att samma uppdatering blir klar. Det är säkert när du återkallade fel post och farligt när certifikatet verkligen är komprometterat, så bestäm först vilket fall du är i. Att radera den betrodda roten är ingen genväg för en förlorad bärbar dator. Att radera en lokal VPN-profil på en maskin ändrar inte vad någon gateway accepterar.

Om identiteten också autentiseras mot en andra gateway behöver båda samma behandling. Den återkallade listan tillhör en gateway, inte prenumerationen.

Relaterade artiklar