Sådan fjerner du et forældet VPN-certifikat fra et tillidslager

Din VPN-klient er afinstalleret, profilen er væk fra Indstillinger, og tunnelen kommer stadig op med de gamle legitimationsoplysninger. Eller du sletter den, genstarter og finder den tilbage næste morgen. Ingen af delene er en defekt slet-knap. En profil er konfiguration; et certifikat er nøglemateriale plus en tillidsbeslutning, der er registreret i et lager, som profilen kun peger på. Hvilken af de to du holder, afgør, hvad 'fjern' skal betyde.

En profil er ikke et certifikat

Tre forskellige objekter kaldes 'certifikatet' i en VPN-opsætning. Klientidentiteten er et slutcertifikat med en privat nøgle, og gatewayen bruger det til at afgøre, hvem du er. Serverens eget slutcertifikat og dets mellemliggende certifikat er det, din klient kontrollerer, når den forbinder. Tillidsankeret, normalt et rod- eller privat CA-certifikat, er det, der overhovedet gør kæden verificerbar. RFC 5280 kalder disse tillidsanker, mellemliggende certifikat og slutenhed, og kæden validerer kun, så længe hvert led signerer det under.

Slet identiteten, og én enhed mister adgang. Slet ankeret, og enhver applikation, der validerer mod det lager, mister evnen til at kontrollere noget som helst udstedt under det, inklusive forbindelser, der ikke har noget med VPN at gøre. Den asymmetri er hele risikoen her: en rod installeret til én gateway er ofte den samme rod, der signerer en intern portal, en mailserver eller et pakkespejl. Husk, hvilken af de to du holder.

Ejerskab afgør, om sletningen bliver slettet. På en bærbar computer, du ejer, er du den eneste, der kan sætte certifikatet tilbage. På en administreret enhed kan en konfigurationsprofil eller en MDM-payload geninstallere det ved næste check-in, og det er derfor, det 'kommer tilbage', og hvorfor hårdere sletning ikke hjælper.

Find ud af, hvilket lager der stadig har det

Folk starter i appen Indstillinger, som er det ene sted, hvor et certifikat ikke gemmes. De rigtige steder er operativsystemets tillidslagre, browserens eget lager og applikationens private lager.

Match på serienummeret eller fingeraftrykket, aldrig på visningsnavnet. Visningsnavne sættes af den, der udstedte certifikatet, og genbruges: 'Example VPN' kan være tre certifikater med tre forskellige nøgler, hvoraf ét stadig bruges dagligt.

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

På macOS giver security-værktøjet de samme fakta, og find-identity viser, hvilke certifikater der stadig har en privat nøgle knyttet:

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

Slet det snævre objekt, behold den fælles udsteder

Eksportér, før du sletter. Uden en sikkerhedskopi er den eneste gendannelse at udstede på ny, hvilket på en privat CA betyder at gå tilbage til den, der driver PKI'en. Den eksporterede PFX er også det, du overdrager, hvis fjernelsen viser sig at være den forkerte beslutning.

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

Flaget -user er det, folk kommer til at udelade. Uden det arbejder certutil på maskinlageret i stedet, hvilket betyder en forhøjet shell, et andet sæt certifikater og en radius, der nu omfatter alle andre konti på maskinen.

På macOS og Linux er formen den samme: identificér, eksportér, fjern derefter fra det snævreste lager, der forklarer symptomet. At fjerne filen under /usr/local/share/ca-certificates og køre update-ca-certificates igen er nok; --fresh hjælper kun, når de symbolske links i /etc/ssl/certs allerede er inkonsistente. RHEL-familien gemmer ankere i /etc/pki/ca-trust/source/anchors, hvor trust anchor --remove gør det samme arbejde.

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

Før du sletter et CA-certifikat, så undersøg, hvad der ellers kæder op til det. At liste emnerne i bundtet er en kontrol på to linjer og besvarer, om det anker gør andet arbejde:

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

At slette filen er ikke at tilbagekalde identiteten

En lokal sletning fjerner én kopi. Den private nøgle kan stadig ligge i en p12 knyttet til en gammel billet, en backup-mappe eller den anden bærbare computer, der blev sat op samtidig. Hvis dette var en klientidentitet, bliver gatewayen ved med at acceptere enhver kopi af den nøgle, indtil identiteten afvises på serversiden.

For en OpenVPN PKI betyder det at tilbagekalde certifikatet og sikre, at den CRL, som crl-verify refererer til, er aktuel; easyrsa revoke derefter easyrsa gen-crl er den korte version. For en gateway knyttet til en identitetsudbyder skal du deaktivere brugeren eller fjerne enheden der, fordi certifikatet kun er én legitimationsoplysning i spil. At slette den lokale kopi, mens kontoen forbliver aktiv, ligner oprydning og er det ikke.

Hændelsesarbejde har en anden rækkefølge: bevar først certifikatet, dets serienummer og tilbagekaldelsesregistreringen, og slet og tilbagekald derefter. De registreringer koster intet og kræver ikke, at en fungerende legitimationsoplysning bliver liggende.

Verificér med et håndtryk og en anden app

Kontrollér kæden udefra, ikke fra lagerlisten, du lige har redigeret. Lageret viser din redigering; håndtrykket viser 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 returkode på 0 betyder, at de resterende ankere stadig validerer gatewayen. En kædefejl efter fjernelse af ankeret er det forventede resultat, og det bekræfter, at du ramte det anker, der er i brug, frem for en dublet i et lager, klienten aldrig læser. Hvis forbindelsen stadig virker, så se efter en anden kopi, et app-bundtet lager eller et fastgjort certifikat, alle almindelige i klienter, der leverer deres egen tillidsliste.

Test derefter noget urelateret: et internt websted, en mailklient, et pakkespejl. Det måler radius billigt, før ændringsvinduet lukker.

• Rolle identificeret som identitet, mellemliggende certifikat eller tillidsanker
• Serienummer og fingeraftryk registreret, og kopien eksporteret til det godkendte sted
• Sletning udført i det snævreste omfang, der forklarer symptomet
• Server-side autorisation tilbagekaldt, da en person eller enhed forlod
• Håndtryk forklaret, og en urelateret app testet igen
• MDM-payload eller administrationsprofil opdateret, ellers kommer certifikatet tilbage

Hvis certifikatet er tilbage efter en genstart, er arbejdet ikke færdigt: noget ejer det og geninstallerer det. Find den ejer, før du sletter igen, for en tredje sletning vil opføre sig præcis som de første to.