Come rimuovere un certificato VPN obsoleto da un archivio di fiducia

Il client VPN è disinstallato, il profilo è sparito dalle Impostazioni, e il tunnel si alza ancora con le vecchie credenziali. Oppure lo eliminate, riavviate e lo ritrovate la mattina dopo. Nessuno dei due è un pulsante di eliminazione rotto. Un profilo è configurazione; un certificato è materiale di chiave più una decisione di fiducia registrata in un archivio a cui il profilo solo punta. Quale dei due avete in mano decide cosa deve significare 'rimuovere'.

Un profilo non è un certificato

Tre oggetti diversi vengono chiamati 'il certificato' in una configurazione VPN. L'identità del client è un certificato foglia con una chiave privata, e il gateway la usa per decidere chi siete. La foglia propria del server e il suo intermedio sono ciò che il client verifica quando si connette. L'ancora di fiducia, di solito un certificato radice o di CA privata, è ciò che rende la catena verificabile del tutto. RFC 5280 chiama questi ancora di fiducia, intermedio ed entità finale, e la catena è valida solo finché ogni anello firma quello sotto.

Eliminate l'identità e un dispositivo perde l'accesso. Eliminate l'ancora e ogni applicazione che convalida contro quell'archivio perde la capacità di controllare qualsiasi cosa emessa sotto di essa, comprese connessioni che non hanno nulla a che fare con la VPN. Questa asimmetria è tutto il rischio qui: una radice installata per un gateway è spesso la stessa radice che firma un portale interno, un server di posta o uno specchio dei pacchetti. Ricordate quale delle due avete in mano.

La proprietà decide se l'eliminazione resta eliminata. Su un portatile che possedete, solo voi potete rimettere il certificato. Su un dispositivo gestito, un profilo di configurazione o un payload MDM possono reinstallarlo al prossimo check-in, ed è per questo che 'torna' e perché eliminare più duramente non aiuta.

Scoprite quale archivio lo tiene ancora

Le persone partono dall'app Impostazioni, che è l'unico posto dove un certificato non viene memorizzato. Le posizioni reali sono gli archivi di fiducia del sistema operativo, l'archivio proprio del browser e l'archivio privato dell'applicazione.

Confrontate il numero di serie o l'impronta, mai il nome visualizzato. I nomi visualizzati li imposta chi ha emesso il certificato e vengono riutilizzati: 'Example VPN' possono essere tre certificati con tre chiavi diverse, uno ancora in uso quotidiano.

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

Su macOS lo strumento security dà gli stessi fatti, e find-identity mostra quali certificati hanno ancora una chiave privata allegata:

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

Eliminate l'oggetto stretto, conservate l'emittente condiviso

Esportate prima di eliminare. Senza un backup l'unico recupero è la riemissione, che su una CA privata significa tornare da chi gestisce la PKI. Il PFX esportato è anche ciò che consegnate se la rimozione si rivela la decisione sbagliata.

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

Il -user flag è quello che le persone tralasciano per errore. Senza di esso certutil lavora sull'archivio della macchina, il che significa una shell elevata, un diverso insieme di certificati e un raggio d'impatto che ora include ogni altro account sulla macchina.

Su macOS e Linux la forma è la stessa: identificate, esportate, poi rimuovete dall'archivio più stretto che spiega il sintomo. Rimuovere il file sotto /usr/local/share/ca-certificates e rieseguire update-ca-certificates è sufficiente; --fresh aiuta solo quando i link simbolici in /etc/ssl/certs sono già incoerenti. I sistemi della famiglia RHEL tengono le ancore in /etc/pki/ca-trust/source/anchors, dove trust anchor --remove fa lo stesso lavoro.

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

Prima di eliminare un certificato CA, controllate cos'altro si concatena a esso. Elencare i soggetti nel bundle è un controllo di due righe e risponde se quell'ancora fa altro lavoro:

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

Eliminare il file non è revocare l'identità

Un'eliminazione locale toglie una copia. La chiave privata può ancora stare in un p12 allegato a un vecchio ticket, a una cartella di backup o al secondo portatile configurato nello stesso momento. Se questa era un'identità client, il gateway continua ad accettare qualsiasi copia di quella chiave finché l'identità non viene rifiutata lato server.

Per una OpenVPN PKI, ciò significa revocare il certificato e assicurarsi che la CRL a cui fa riferimento crl-verify sia aggiornata; easyrsa revoke poi easyrsa gen-crl è la versione breve. Per un gateway legato a un provider di identità, disattivate l'utente o rimuovete il dispositivo lì, perché il certificato è solo una credenziale in gioco. Eliminare la copia locale mentre l'account resta attivo sembra pulizia e non lo è.

Il lavoro di incidente ha un altro ordine: conservate prima il certificato, il suo numero di serie e il registro di revoca, poi eliminate e revocate. Quei registri non costano nulla e non richiedono di lasciare una credenziale funzionante al suo posto.

Verificate con un handshake e una seconda app

Controllate la catena dall'esterno, non dall'elenco dell'archivio appena modificato. L'archivio mostra la vostra modifica; l'handshake mostra il risultato.

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

Un codice di ritorno 0 significa che le ancore rimanenti convalidano ancora il gateway. Un errore di catena dopo la rimozione dell'ancora è l'esito atteso, e conferma che avete colpito l'ancora in uso e non un duplicato in un archivio che il client non legge mai. Se la connessione funziona ancora, cercate una seconda copia, un archivio incorporato nell'app o un certificato appuntato, tutti comuni nei client che portano la propria lista di fiducia.

Poi provate qualcosa di non correlato: un sito interno, un client di posta, uno specchio dei pacchetti. Questo misura il raggio d'impatto a basso costo prima che la finestra di cambiamento si chiuda.

• Ruolo identificato come identità, intermedio o ancora di fiducia
• Numero di serie e impronta registrati, e la copia esportata nella posizione approvata
• Eliminazione eseguita nell'ambito più stretto che spiega il sintomo
• Autorizzazione lato server revocata quando una persona o un dispositivo se n'è andato
• Handshake spiegato, e un'app non correlata ritestata
• Payload MDM o profilo di gestione aggiornato, altrimenti il certificato torna

Se il certificato è tornato dopo un riavvio, il lavoro non è finito: qualcosa lo possiede e lo reinstalla. Trovate quel proprietario prima di eliminare di nuovo, perché una terza eliminazione si comporterà esattamente come le prime due.