VPN-klienten din er avinstallert, profilen er borte fra Innstillinger, og tunnelen kommer likevel opp med de gamle påloggingsdataene. Eller du sletter den, starter på nytt og finner den tilbake neste morgen. Ingen av delene er en ødelagt slett-knapp. En profil er konfigurasjon; et sertifikat er nøkkelmateriale pluss en tillitsbeslutning registrert i et lager som profilen bare peker på. Hvilken av de to du holder i hånden avgjør hva 'fjern' må bety.

En profil er ikke et sertifikat

Tre forskjellige objekter kalles 'sertifikatet' i et VPN-oppsett. Klientidentiteten er et løvnode-sertifikat med en privat nøkkel, og gatewayen bruker det til å avgjøre hvem du er. Serverens eget løvnode-sertifikat og mellomleddet er det klienten din sjekker når den kobler til. Tillitsankeret, vanligvis et rot- eller privat CA-sertifikat, er det som gjør kjeden verifiserbar i det hele tatt. RFC 5280 kaller disse tillitsankeret, mellomleddet og sluttentiteten, og kjeden valideres bare så lenge hvert ledd signerer det under.

Slett identiteten, og én enhet mister tilgangen. Slett ankeret, og hver applikasjon som validerer mot det lageret, mister evnen til å sjekke noe som helst utstedt under det, inkludert tilkoblinger som ikke har noe med VPN å gjøre. Den asymmetrien er hele risikoen her: et rot installert for én gateway er ofte det samme roten som signerer en intern portal, en e-postserver eller et pakkespeil. Husk hvilken av de to du holder i hånden.

Eierskap avgjør om slettingen blir slettet. På en bærbar PC du eier, er du den eneste som kan sette sertifikatet tilbake. På en administrert enhet kan en konfigurasjonsprofil eller en MDM-nyttelast installere det på nytt ved neste innsjekking, og det er derfor det 'kommer tilbake' og derfor hardere sletting ikke hjelper.

Finn hvilket lager som fortsatt har det

Folk begynner i Innstillinger-appen, som er det ene stedet et sertifikat ikke lagres. De virkelige stedene er operativsystemets tillitslagre, nettleserens eget lager og applikasjonens private lager.

StoreWhat deleting from it affects
Windows CurrentUser\Myyour login session only
Windows LocalMachine Rootevery user and service on the machine
macOS login or System keychainone account, or all of them with sudo
Linux ca-certificates bundlecurl, git, Python, anything using the system bundle
Firefox cert9.dbFirefox only; it does not read the OS store

Match på serienummeret eller fingeravtrykket, aldri på visningsnavnet. Visningsnavn settes av den som utstedte sertifikatet og gjenbrukes: 'Example VPN' kan være tre sertifikater med tre forskjellige nøkler, ett fortsatt i daglig bruk.

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

På macOS gir security-verktøyet de samme fakta, og find-identity viser hvilke sertifikater som fortsatt har en privat nøkkel tilknyttet:

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

Slett det smale objektet, behold den felles utstederen

Eksporter før du sletter. Uten en sikkerhetskopi er den eneste gjenopprettingen å utstede på nytt, som på en privat CA betyr å gå tilbake til den som driver PKI-en. Den eksporterte PFX-filen er også det du overleverer hvis fjerningen viser seg å være feil beslutning.

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

Flagget -user er det folk mister ved et uhell. Uten det jobber certutil mot maskinlageret i stedet, noe som betyr et forhøyet skall, et annet sett sertifikater og en skadeflate som nå omfatter alle andre kontoer på maskinen.

På macOS og Linux er formen den samme: identifiser, eksporter, og fjern deretter fra det smaleste lageret som forklarer symptomet. Å fjerne filen under /usr/local/share/ca-certificates og kjøre update-ca-certificates på nytt er nok; --fresh hjelper bare når symbolkoblingene i /etc/ssl/certs allerede er inkonsistente. Systemer i RHEL-familien holder ankere i /etc/pki/ca-trust/source/anchors, der trust anchor --remove gjør den samme jobben.

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-sertifikat, sjekk hva annet som kjedekobler til det. Å liste opp subjektene i bunten er en sjekk på to linjer, og den svarer på om ankeret gjør annet arbeid:

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

Å slette filen er ikke å tilbakekalle identiteten

En lokal sletting fjerner én kopi. Den private nøkkelen kan fortsatt ligge i en p12 festet til en gammel billett, en sikkerhetskopimappe eller den andre bærbare PC-en som ble satt opp samtidig. Hvis dette var en klientidentitet, fortsetter gatewayen å godta enhver kopi av den nøkkelen til identiteten avvises på serversiden.

For en OpenVPN PKI betyr det å tilbakekalle sertifikatet og sørge for at CRL-en som refereres av crl-verify er oppdatert; easyrsa revoke og deretter easyrsa gen-crl er kortversjonen. For en gateway knyttet til en identitetsleverandør, deaktiver brukeren eller fjern enheten der, fordi sertifikatet bare er én legitimasjon i spill. Å slette den lokale kopien mens kontoen forblir aktiv ser ut som opprydding og er det ikke.

Hendelsesarbeid har en annen rekkefølge: bevar sertifikatet, serienummeret og tilbakekallingsposten først, og slett og tilbakekall deretter. De postene koster ingenting og krever ikke at en fungerende legitimasjon blir liggende.

Verifiser med en håndtrykk og en andre app

Sjekk kjeden utenfra, ikke fra lagerlisten du nettopp redigerte. Lageret viser redigeringen din; 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 betyr at de gjenværende ankerne fortsatt validerer gatewayen. En kjedefeil etter at ankeret er fjernet er det forventede utfallet, og det bekrefter at du traff ankeret som er i bruk og ikke en duplikat i et lager klienten aldri leser. Hvis tilkoblingen fortsatt virker, se etter en andre kopi, et app-innpakket lager eller et pinnet sertifikat, alt vanlig i klienter som leverer sin egen tillitsliste.

Test deretter noe urelatert: et internt nettsted, en e-postklient, et pakkespeil. Det måler skadeflaten billig, før endringsvinduet lukkes.

  • Rollen identifisert som identitet, mellomledd eller tillitsanker
  • Serienummer og fingeravtrykk registrert, og kopien eksportert til det godkjente stedet
  • Sletting utført i det smaleste omfanget som forklarer symptomet
  • Autorisasjon på serversiden tilbakekalt da en person eller enhet forsvant
  • Håndtrykket forklart, og én urelatert app testet på nytt
  • MDM-nyttelast eller administrasjonsprofil oppdatert, ellers kommer sertifikatet tilbake

Hvis sertifikatet er tilbake etter en omstart, er jobben ikke ferdig: noe eier det og installerer det på nytt. Finn den eieren før du sletter igjen, for en tredje sletting vil oppføre seg nøyaktig som de to første.

Relaterte artikler