Quali validatori influenza un certificato radice aggiuntivo?

Trovate un certificato radice che non dovrebbe essere lì, e la prima domanda è quale identità può impersonare. La risposta onesta dipende da quale software consulta quello store e da come la vostra VPN verifica il proprio gateway. Un browser, un gestore di pacchetti e un client VPN con un'impronta bloccata non condividono necessariamente la stessa decisione di fiducia. Mappate i validatori prima di decidere l'ambito.

Una radice nello store di sistema non è una chiave universale

Installare una radice rende i certificati firmati con quella chiave accettabili per i programmi che usano lo store interessato. Non li rende automaticamente accettabili ovunque, perché alcune applicazioni portano il proprio bundle o controllano un valore bloccato. Non dimostra nemmeno che qualcuno abbia eseguito codice sulla macchina; un cambiamento di fiducia è una capacità tra diverse. Trattate il certificato come un riscontro da circoscrivere, non come l'intero incidente.

Lo store conta quanto il certificato: un bundle a livello utente e un'ancora a livello di sistema raggiungono consumatori diversi.

Mappate ogni validatore e la sua fonte di fiducia

Annotate ogni componente che convalida certificati per i flussi di lavoro interessati: browser, gestore di pacchetti, client di posta, VPN. Poi trovate la fonte di fiducia che ciascuno legge.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

L'elenco della directory mostra le ancore aggiunte localmente sui sistemi in stile Debian, e l'elenco di fiducia mostra ciò che lo store di sistema espone attualmente. Un browser con uno store proprio non comparirà lì, e un'applicazione Java o Python può usare un altro bundle ancora. Registrate quali voci sono attese e quali no, usando l'impronta invece del solo nome visualizzato. Quell'elenco è ciò che serve a un responder prima di eliminare qualsiasi cosa.

Controllate la convalida peer della VPN stessa

Una VPN con una CA privata o un'impronta esplicita valuta il gateway in base alla propria configurazione. Confrontate ciò che il client si aspetta con ciò che il gateway presenta.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

L'output fornisce l'impronta SHA-256 e il soggetto del certificato presentato dall'endpoint, che potete confrontare con il valore configurato. OpenVPN ha un'opzione di impronta peer che esegue quel confronto per il tunnel senza richiedere che lo store di sistema accetti il firmatario. Questa indipendenza è utile per il tunnel e non dice nulla sul browser. Non aiuta nemmeno se l'impronta attesa è stata copiata fin dall'inizio dalla connessione sospetta.

Circoscrivete l'incidente oltre il certificato

Usate la procedura del proprietario del dispositivo per rimuovere le ancore non autorizzate e cercare le modifiche che di solito le accompagnano: nuovi servizi, client modificati, impostazioni proxy alterate. Su una macchina gestita, confermate la configurazione legittima prima di eliminare materiale da cui dipende altro software. Per ogni validatore, registrate da dove viene la sua fiducia, quale identità si aspetta e come avete confermato che la configurazione attuale è corretta. Un tunnel funzionante dopo la pulizia è un'osservazione, non la prova che l'endpoint sia pulito.

Poi riprovate i flussi di lavoro che usavano lo store, perché rimuovere un'ancora può rompere un servizio interno che vi faceva legittimamente affidamento. Il ripristino è completo quando le relazioni di fiducia attese funzionano e quelle inattese no.