Ispezionare un certificato VPN senza esporre la sua chiave

Leggere i campi pubblici di un certificato non richiede mai di mostrare la chiave privata che gli corrisponde, e gli strumenti per farlo sono già presenti in ogni sistema che termina una VPN. Il rischio arriva un passo prima: il file che avete ricevuto potrebbe non essere affatto un certificato. Un certificato PEM, un blob DER, un pacchetto PKCS#12 e un OpenVPN profilo possono arrivare con lo stesso nome e contenere materiale molto diverso, quindi identificate il contenitore prima di scegliere un comando.

Tre fatti decidono quale comando è sicuro: cosa contiene il file, cosa dovete leggerne e chi vedrà l'output. Se uno solo di questi è sbagliato, l'ispezione stessa diventa l'incidente.

Quale dei tre file avete ricevuto

Un certificato PEM è testo con marcatori BEGIN ed END visibili, un file DER è binario e richiede un flag di formato in ingresso, e un pacchetto è un contenitore che può custodire una chiave accanto al certificato.file server.crt separa testo e binario in un secondo, e uno sguardo alla prima riga distingue un certificato nudo da un profilo che ne incorpora uno. È qui che tirare a indovinare trasforma un'ispezione in un incidente.

Se il file è un profilo e non un certificato, trattatelo come una credenziale finché non avete prove contrarie. Quell'assunzione non costa nulla e previene l'errore più comune di tutto questo lavoro.

Leggere i campi pubblici di un certificato PEM

Per un certificato che siete autorizzati a ispezionare, il sottocomando x509 con -noout stampa i campi scelti e nulla più. Sopprimere il corpo è ciò che mantiene l'output sui metadati, e proprio questo lo rende sicuro da incollare in un ticket. I selettori qui sotto sono quelli pubblici, e la documentazione di openssl x509 elenca il resto.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Su un certificato di test generato localmente quel comando stampa una riga di soggetto e una di emittente, la coppia notBefore e notAfter e un'impronta SHA-256. Quei campi identificano l'oggetto; non stabiliscono un percorso di fiducia valido, che è un compito di verifica separato con un proprio comando e una propria risposta. Un file di catena può anche stampare solo il primo certificato se non iterate voi stessi sul file. Confrontare due file in questo modo costa un comando e chiarisce quale dei due il peer presenta davvero.

Pacchetti che custodiscono una chiave accanto al certificato

Un file .p12o .pfx può contenere una chiave privata, e il comando di analisi la stampa se non sopprimete quella parte dell'output. Con -nokeys lo stesso comando riporta comunque la struttura del contenitore, compreso un sacchetto di chiave protetto, senza emettere alcun materiale di chiave; togliete quel flag e un blocco di chiave compare nel terminale e nella cronologia della shell.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Un profilo OpenVPN incorpora lo stesso materiale come testo, quindi il confine è visibile se sapete dove guardare. Il materiale pubblico sta tra BEGIN CERTIFICATE ed END CERTIFICATE, mentre qualsiasi cosa tra BEGIN PRIVATE KEY e la sua riga END corrispondente è la chiave e non deve lasciare l'host. Copiare il profilo per intero pubblica entrambi.

Ottenere il valore di riferimento altrove

Un'impronta letta dalla connessione che state cercando di verificare non prova nulla, perché l'ha fornita la parte di cui diffidate. Non è un argomento contro le impronte; è un argomento sulla provenienza. Confrontate il valore con uno ottenuto attraverso un canale su cui il peer non può scrivere, come il certificato pubblicato in un repository interno o l'hash stampato in un record di modifica firmato.

Dove un archivio di fiducia esegue la validazione, lasciategliela fare e leggete l'errore che produce invece di sostituirlo con un confronto vostro. La distinzione che conta è chi ha fornito il riferimento, non quale funzione di hash è stata usata.

Condividere il risultato e cosa fare dopo una svista

Inviate l'errore di validazione esatto, le date pertinenti e solo i dettagli di identità che il destinatario richiede. I nomi host interni e gli identificatori di account restano sensibili anche quando non è presente alcuna chiave, e un servizio di paste pubblico è la destinazione sbagliata per tutto questo. Incollate nel ticket, non in un buffer temporaneo condiviso con altri.

Se materiale di chiave è comparso sullo schermo o in un file, trattatelo come compromesso e ruotatelo invece di sperare che nessuno abbia guardato. Poi annotate il file ispezionato, il comando usato e dove è finito l'output, perché è quel verbale che trasforma uno spavento in una procedura. La rotazione costa poco rispetto al prezzo di dare per scontato che nessuno abbia tenuto uno screenshot, e lo stesso verbale dice all'ingegnere successivo quali file sono stati toccati. Fate entrambe le cose prima che il ticket venga chiuso.