Så tar du bort ett föråldrat VPN-certifikat från ett förtroendelager

Din VPN-klient är avinstallerad, profilen är borta från Inställningar och tunneln kommer ändå upp med de gamla inloggningsuppgifterna. Eller så raderar du den, startar om och hittar den igen nästa morgon. Inget av det är en trasig raderingsknapp. En profil är konfiguration; ett certifikat är nyckelmaterial plus ett förtroendebeslut som registrerats i ett lager som profilen bara pekar på. Vilket av de två du håller i avgör vad 'ta bort' måste betyda.

En profil är inte ett certifikat

I en VPN-konfiguration kallas tre olika objekt 'certifikatet'. Klientidentiteten är ett lövcertifikat med en privat nyckel, och gatewayen använder det för att avgöra vem du är. Serverns eget lövcertifikat och dess mellanliggande certifikat är det din klient kontrollerar när den ansluter. Förtroendeankaret, vanligtvis ett rot- eller privat CA-certifikat, är det som gör kedjan verifierbar över huvud taget. RFC 5280 kallar dessa för förtroendeankaret, mellanliggande och slutentiteten, och kedjan valideras bara så länge varje länk signerar länken under sig.

Radera identiteten och en enhet förlorar åtkomsten. Radera ankaret och varje program som validerar mot det lagret förlorar förmågan att kontrollera något som helst utfärdat under det, inklusive anslutningar som inte har något med VPN att göra. Den asymmetrin är hela risken här: en rot installerad för en gateway är ofta samma rot som signerar en intern portal, en e-postserver eller en paketspegel. Kom ihåg vilket av de två du håller i.

Ägandet avgör om raderingen förblir raderad. På en laptop du äger är du den enda som kan sätta tillbaka certifikatet. På en hanterad enhet kan en konfigurationsprofil eller en MDM-nyttolast installera om det vid nästa incheckning, vilket är varför det 'kommer tillbaka' och varför hårdare radering inte hjälper.

Ta reda på vilket lager som fortfarande har det

Folk börjar i appen Inställningar, som är den enda platsen där ett certifikat inte lagras. De verkliga platserna är operativsystemets förtroendelager, webbläsarens eget lager och programmets privata lager.

Matcha på serienumret eller fingeravtrycket, aldrig på visningsnamnet. Visningsnamn sätts av den som utfärdade certifikatet och återanvänds: 'Example VPN' kan vara tre certifikat med tre olika nycklar, ett fortfarande i daglig användning.

certutil -user -store My
certutil -store Root
openssl x509 -in vpn-client.pem -noout -subject -issuer -serial -fingerprint -sha256

På macOS ger verktyget security samma fakta, och find-identity visar vilka certifikat som fortfarande har en privat nyckel kopplad:

security find-certificate -a -c "Example VPN" -Z /Library/Keychains/System.keychain
security find-identity -v -p ssl-client

Radera det smala objektet, behåll den delade utfärdaren

Exportera innan du raderar. Utan en säkerhetskopia är den enda återställningen att utfärda på nytt, vilket på en privat CA innebär att gå tillbaka till den som driver PKI:n. Den exporterade PFX-filen är också det du överlämnar om borttagningen visar sig vara fel beslut.

certutil -user -exportPFX -p backup My <serial> C:\temp\vpn-id.pfx
certutil -user -delstore My <serial>
Remove-Item Cert:\CurrentUser\My<thumbprint>

Flaggan -user är den som folk tappar av misstag. Utan den arbetar certutil mot maskinlagret i stället, vilket betyder ett förhöjt skal, en annan uppsättning certifikat och en skadradie som nu omfattar alla andra konton på maskinen.

På macOS och Linux är formen densamma: identifiera, exportera och ta sedan bort från det smalaste lagret som förklarar symtomet. Att ta bort filen under /usr/local/share/ca-certificates och köra update-ca-certificates igen räcker; --fresh hjälper bara när symboliska länkar i /etc/ssl/certs redan är inkonsistenta. System i RHEL-familjen håller ankare i /etc/pki/ca-trust/source/anchors, där trust anchor --remove gör samma jobb.

sudo security delete-certificate -Z <sha1> /Library/Keychains/System.keychain
sudo rm /usr/local/share/ca-certificates/example-vpn.crt
sudo update-ca-certificates
sudo trust anchor --remove /etc/pki/ca-trust/source/anchors/example-vpn.crt

Innan du raderar ett CA-certifikat, kontrollera vad mer som kedjar till det. Att lista subjekten i paketet är en kontroll på två rader och den svarar på om det ankaret gör annat arbete:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep -i example

Att radera filen är inte att återkalla identiteten

En lokal radering tar bort en kopia. Den privata nyckeln kan fortfarande ligga i en p12 kopplad till en gammal biljett, en säkerhetskopiemapp eller den andra laptop som ställdes in samtidigt. Om detta var en klientidentitet fortsätter gatewayen att acceptera vilken kopia som helst av den nyckeln tills identiteten avvisas på serversidan.

För en OpenVPN PKI innebär det att återkalla certifikatet och se till att CRL:n som refereras av crl-verify är aktuell; easyrsa revoke och sedan easyrsa gen-crl är kortversionen. För en gateway knuten till en identitetsleverantör, inaktivera användaren eller ta bort enheten där, eftersom certifikatet bara är en inloggningsuppgift i spelet. Att radera den lokala kopian medan kontot förblir aktivt ser ut som städning och är det inte.

Incidentarbete har en annan ordning: bevara certifikatet, dess serienummer och återkallningsposten först, radera och återkalla sedan. De posterna kostar ingenting och kräver inte att en fungerande inloggningsuppgift lämnas kvar.

Verifiera med en handskakning och en andra app

Kontrollera kedjan utifrån, inte från lagerlistan du just redigerade. Lagret visar din ändring; handskakningen visar resultatet.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error < /dev/null
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt vpn-gateway.pem

En returkod på 0 betyder att de återstående ankarna fortfarande validerar gatewayen. Ett kedjefel efter att ankaret tagits bort är det förväntade utfallet, och det bekräftar att du träffade ankaret som används och inte en dubblett i ett lager som klienten aldrig läser. Om anslutningen fortfarande fungerar, leta efter en andra kopia, ett app-inbäddat lager eller ett pinnat certifikat, allt vanligt hos klienter som levererar sin egen förtroendelista.

Testa sedan något orelaterat: en intern webbplats, en e-postklient, en paketspegel. Det mäter skadradien billigt, innan ändringsfönstret stängs.

• Roll identifierad som identitet, mellanliggande eller förtroendeankare
• Serienummer och fingeravtryck registrerade, och kopian exporterad till den godkända platsen
• Borttagning gjord i den smalaste omfattning som förklarar symtomet
• Auktorisering på serversidan återkallad när en person eller enhet lämnade
• Handskakningen förklarad, och en orelaterad app testad igen
• MDM-nyttolast eller hanteringsprofil uppdaterad, annars kommer certifikatet tillbaka

Om certifikatet är tillbaka efter en omstart är jobbet inte klart: något äger det och installerar om det. Hitta den ägaren innan du raderar igen, för en tredje radering beter sig exakt som de två första.