Stesso nome file ca.crt, certificato diverso: cosa confrontare

Due profili forniscono entrambi un file chiamato ca.crt, un tunnel sale e l’altro fallisce con un errore di catena. Aprire i due file affiancati raramente risolve la questione, e disattivare la verifica la risolve nella direzione sbagliata. La domanda che l’errore pone davvero è più stretta: quale certificato carica ciascun processo come ancora di fiducia, e i due sono lo stesso oggetto? Rispondi prima a questo e il resto della diagnosi prende una direzione. Il nome del file è un’etichetta di imballaggio, e anche il percorso scritto nel profilo non è autorevole, quindi tutto dipende da ciò che il processo legge davvero.

Trova il certificato che il client carica davvero

OpenVPN accetta l’autorità in due forme, e la forma decide quali byte contano. Un profilo può puntare a un file esterno con ca, oppure incorporare il certificato in un blocco <ca> nel profilo stesso. Quando esistono entrambi, vince il blocco incorporato e il file accanto al profilo non viene mai aperto.

Leggi il profilo che fallisce e scopri quale forma usa prima di confrontare qualsiasi cosa. Una copia presa da una directory vicina, o dal pacchetto da cui è arrivato l’altro profilo, non ti dice nulla su ciò di cui si fida questo processo. Lo stesso vale per il percorso nella configurazione: viene risolto rispetto al punto in cui è stato avviato il client, che non sempre è la directory che stai guardando. Leggi il profilo, non la cartella.

I certificati si identificano dal loro contenuto: la chiave pubblica, il soggetto e l’emittente, la finestra di validità e la firma su tutto ciò. Due file con byte identici sono lo stesso certificato comunque si chiamino, e due file con lo stesso nome possono essere autorità non correlate. Il nome è un’etichetta di imballaggio, non un’identità.

Impronta le due copie con openssl

Un’impronta è un hash sulla codifica DER del certificato, la forma che la firma copre, quindi i fine riga e il testo dell’intestazione non possono influenzarla. Calcolala per ogni file e ottieni due stringhe esadecimali separate da due punti che o corrispondono o no. Non serve leggere altro nel certificato per rispondere alla domanda del confronto.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

È tentante puntare openssl sul profilo stesso, ma legge il primo blocco di certificato che compare nel file, e un profilo di solito porta <cert> prima di <ca>. Estrai il blocco dell’autorità, poi impronta il file estratto, perché è la copia che il client userà davvero.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Impronte identiche significano che il materiale di fiducia è lo stesso e che l’errore di catena ha un’altra causa, il che è un’altra indagine. Impronte diverse significano certificati diversi, ed è lì che inizia la sezione successiva.

Leggi una discrepanza prima di supporre un attacco

Impronte diverse significano certificati diversi e nulla di più. Una riemissione, una rotazione, un’autorità rinominata o un bundle obsoleto producono tutti file diversi con storie del tutto legittime. Quale appartiene al deployment è una domanda per l’operatore o per il registro di deployment, non per l’ora di modifica del file. Gli archivi copiano i timestamp, quindi un file più recente non è automaticamente l’ancora corretta.

Una radice che firma se stessa è normale, quindi trovarne una non è prova di un problema. Il compito del verificatore è costruire un percorso dal certificato del server all’ancora che gli è stata consegnata, e un errore di catena di solito significa che quel percorso non è potuto essere completato.

Controlla se l’ancora del profilo che fallisce è un’autorità da cui il deployment emette ancora. Se l’impronta non corrisponde a nulla nel registro di deployment, il profilo è semplicemente obsoleto, e nessuna messa a punto lato client lo sistemerà.

Ripara la fiducia senza disattivare la verifica

La correzione a breve termine è disattivare la verifica o aggiungere ogni certificato della catena come ancora. Entrambe fanno sparire il messaggio, ed entrambe cambiano quali server il client accetterà da quel momento. Riattiva la verifica, installa l’ancora prevista e riprova.

Se la catena ora si costruisce ma compare un altro errore, è un progresso: verifica del nome, date di validità e revoca sono controlli separati con messaggi separati. Tieni la coppia di impronte e il testo originale dell’errore insieme nel ticket, così la persona successiva vede quale ancora è stata caricata e quale era attesa. Una coppia di impronte è abbastanza piccola da incollarla in una nota di passaggio, e l’occorrenza successiva richiede allora cinque minuti invece di un pomeriggio.

Ottieni l’autorità corretta attraverso lo stesso canale autenticato che ha consegnato il profilo. Prelevare un certificato dal server perché il suo soggetto sembra familiare è un altro atto, e amplia silenziosamente ciò di cui il client si fiderà.