Een verouderd VPN-certificaat uit een truststore verwijderen

Je VPN-client is verwijderd, het profiel is weg uit Instellingen, en toch komt de tunnel weer op met de oude inloggegevens. Of je verwijdert hem, herstart en vindt hem de volgende ochtend terug. Geen van beide is een kapotte verwijderknop. Een profiel is configuratie; een certificaat is sleutelmateriaal plus een vertrouwensbeslissing die is vastgelegd in een opslag waarnaar het profiel alleen verwijst. Welke van de twee je in handen hebt, bepaalt wat 'verwijderen' moet betekenen.

Een profiel is geen certificaat

In een VPN-opstelling worden drie verschillende objecten 'het certificaat' genoemd. De clientidentiteit is een bladcertificaat met een privésleutel, en de gateway gebruikt het om te bepalen wie je bent. Het bladcertificaat van de server zelf en zijn intermediair zijn wat je client controleert bij het verbinden. De trust anchor, meestal een root- of particulier CA-certificaat, is wat de keten überhaupt verifieerbaar maakt. RFC 5280 noemt deze de trust anchor, het intermediair en de eindentiteit, en de keten valideert alleen zolang elke schakel de schakel eronder ondertekent.

Verwijder de identiteit en één apparaat verliest toegang. Verwijder de anchor en elke applicatie die tegen die opslag valideert, verliest het vermogen om iets te controleren dat eronder is uitgegeven, inclusief verbindingen die niets met de VPN te maken hebben. Die asymmetrie is hier het hele risico: een root die voor één gateway is geïnstalleerd, is vaak dezelfde root die een intern portaal, een mailserver of een pakketspiegel ondertekent. Onthoud welke van de twee je in handen hebt.

Eigendom bepaalt of de verwijdering verwijderd blijft. Op een laptop die je bezit, ben jij de enige die het certificaat terug kan zetten. Op een beheerd apparaat kan een configuratieprofiel of een MDM-payload het bij de volgende check-in opnieuw installeren, waardoor het 'terugkomt' en waarom harder verwijderen niet helpt.

Zoek welke opslag het nog bevat

Mensen beginnen in de app Instellingen, de enige plek waar een certificaat niet wordt opgeslagen. De echte locaties zijn de truststores van het besturingssysteem, de eigen opslag van de browser en de privéopslag van de applicatie.

Vergelijk op het serienummer of de vingerafdruk, nooit op de weergavenaam. Weergavenamen worden ingesteld door degene die het certificaat uitgeeft en worden hergebruikt: 'Example VPN' kunnen drie certificaten met drie verschillende sleutels zijn, waarvan één nog dagelijks in gebruik is.

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

Op macOS geeft de tool security dezelfde feiten, en find-identity laat zien welke certificaten nog een privésleutel hebben:

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

Verwijder het smalle object, behoud de gedeelde uitgever

Exporteer voordat je verwijdert. Zonder back-up is de enige herstelmogelijkheid opnieuw uitgeven, wat bij een particuliere CA betekent teruggaan naar wie de PKI beheert. De geëxporteerde PFX is ook wat je overhandigt als de verwijdering de verkeerde keuze blijkt.

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

De -user vlag is degene die mensen per ongeluk weglaten. Zonder die vlag werkt certutil op de machineopslag in plaats daarvan, wat een verhoogde shell, een andere set certificaten en een blast radius betekent die nu elk ander account op de machine omvat.

Op macOS en Linux is de vorm hetzelfde: identificeer, exporteer en verwijder dan uit de smalste opslag die het symptoom verklaart. Het bestand onder /usr/local/share/ca-certificates verwijderen en update-ca-certificates opnieuw uitvoeren is genoeg; --fresh helpt alleen wanneer de symlinks in /etc/ssl/certs al inconsistent zijn. Systemen uit de RHEL-familie bewaren anchors in /etc/pki/ca-trust/source/anchors, waar trust anchor --remove hetzelfde werk doet.

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

Controleer voordat je een CA-certificaat verwijdert wat er nog meer aan koppelt. De subjecten in de bundel opsommen is een controle van twee regels en beantwoordt of die anchor ander werk doet:

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

Het bestand verwijderen is de identiteit niet intrekken

Een lokale verwijdering haalt één kopie weg. De privésleutel kan nog in een p12 zitten die aan een oud ticket hangt, in een back-upmap of op de tweede laptop die tegelijk is ingesteld. Als dit een clientidentiteit was, blijft de gateway elke kopie van die sleutel accepteren tot de identiteit server-side wordt geweigerd.

Voor een OpenVPN PKI betekent dat het certificaat intrekken en ervoor zorgen dat de CRL waarnaar crl-verify verwijst actueel is; easyrsa revoke en dan easyrsa gen-crl is de korte versie. Voor een gateway die aan een identiteitsprovider hangt, schakel je de gebruiker daar uit of verwijder je het apparaat, want het certificaat is slechts één inloggegeven in het spel. De lokale kopie verwijderen terwijl het account actief blijft, lijkt op opruimen en is dat niet.

Incidentwerk heeft een andere volgorde: bewaar eerst het certificaat, het serienummer en de intrekkingsregistratie, en verwijder en trek daarna in. Die registraties kosten niets en vereisen niet dat er een werkend inloggegeven blijft staan.

Verifieer met een handshake en een tweede app

Controleer de keten van buitenaf, niet vanuit de opslaglijst die je net hebt bewerkt. De opslag toont je bewerking; de handshake toont het resultaat.

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

Een retourcode van 0 betekent dat de resterende anchors de gateway nog valideren. Een ketenfout na het verwijderen van de anchor is de verwachte uitkomst, en het bevestigt dat je de anchor raakte die in gebruik is en niet een duplicaat in een opslag die de client nooit leest. Als de verbinding nog werkt, zoek dan een tweede kopie, een in de app ingebouwde opslag of een vastgepind certificaat, allemaal gebruikelijk bij clients die hun eigen vertrouwenslijst meeleveren.

Test daarna iets ongerelateerds: een interne site, een mailclient, een pakketspiegel. Dat meet de blast radius goedkoop, voordat het wijzigingsvenster sluit.

• Rol geïdentificeerd als identiteit, intermediair of trust anchor
• Serienummer en vingerafdruk vastgelegd, en de kopie geëxporteerd naar de goedgekeurde locatie
• Verwijdering uitgevoerd in de smalste scope die het symptoom verklaart
• Autorisatie aan de serverkant ingetrokken toen een persoon of apparaat vertrok
• Handshake verklaard, en één ongerelateerde app opnieuw getest
• MDM-payload of beheerprofiel bijgewerkt, anders komt het certificaat terug

Als het certificaat na een herstart terug is, is het werk niet klaar: iets bezit het en installeert het opnieuw. Vind die eigenaar voordat je weer verwijdert, want een derde verwijdering gedraagt zich precies zoals de eerste twee.