Certificato VPN auto-firmato: cosa significa e di cosa si fida

Due convinzioni fanno qui i danni maggiori: che un certificato VPN auto-firmato significhi che il tunnel non è cifrato, e che installare qualunque cosa abbia chiesto il client VPN riguardi solo la VPN. Nessuna delle due sopravvive al contatto con una distribuzione reale. Un certificato auto-firmato descrive una relazione di firma, non un verdetto di sicurezza, e la portata della fiducia che aggiungi dipende da in quale archivio finisce. Ho visto un helpdesk importare una radice di fornitore in una macchina Windows per far tacere un avviso, poi passare un pomeriggio a spiegare perché il browser aveva smesso di lamentarsi di un portale non correlato. Le due metà di questa domanda vanno insieme, quindi trattale come una sola.

Un certificato non è un archivio di fiducia

Il file che il server presenta porta una chiave pubblica, un nome di soggetto, un nome di emittente, date di validità ed estensioni. Auto-firmato significa che soggetto ed emittente sono la stessa entità e la firma viene verificata con la chiave del certificato stesso. Nulla in quella definizione dice che la connessione è debole, e nulla dice che il client l’accetterà.

L’accettazione viene da altrove: un file CA verso cui punti il client, un’impronta che confronti a mano, o una radice che già si trova in un archivio che il client legge. Una distribuzione può essere perfettamente sana mentre il suo certificato fallirebbe ogni test pubblico. openssl verify contro il pacchetto di sistema segnalerà un emittente sconosciuto, e quel rapporto è corretto, non un difetto.

L’opzione ca di OpenVPN è il caso più chiaro di fiducia limitata all’applicazione. Quel file nomina le ancore che il client accetterà, e può contenere una CA privata oppure, in una piccola distribuzione, il certificato auto-firmato del server stesso. La versione 2.6 accetta anche --peer-fingerprint per fissare un’impronta SHA-256 invece di distribuire un file CA. WireGuard sta ancora più fuori: non ha alcun certificato, solo una chiave pubblica statica per peer, quindi la questione dell’auto-firma non gli si applica.

Dove installi la fiducia decide chi la eredita

Metti lo stesso certificato in tre posti e ottieni tre raggi d’azione diversi. Un pacchetto letto solo dal client VPN riguarda quel client. Una radice nell’archivio del sistema operativo riguarda ogni programma che consulta quell’archivio. Un browser con il proprio database di fiducia può ignorare entrambi, ed è per questo che un avviso può sopravvivere a un’importazione che sembrava funzionare.

Su Debian o Ubuntu, lasciare un file in /usr/local/share/ca-certificates/ ed eseguire update-ca-certificates modifica il pacchetto a livello di sistema. Su Windows, certutil -addstore -f Root scrive nell’archivio della macchina e richiede un prompt elevato, mentre aggiungere -user punta invece all’archivio dell’utente corrente; i due non sono intercambiabili. Firefox mantiene il proprio database NSS, quindi un’importazione a livello di sistema operativo potrebbe non comparire mai lì.

La portata conta per ciò che un’autorità può fare. Una CA emittente può firmare nomi con cui non ha alcun rapporto, quindi tutto ciò che si fida di quell’archivio accetterà quelle firme. Una singola foglia fissata non può farlo; autentica esattamente un’identità di peer. Se l’obiettivo è far connettere una VPN, una CA limitata all’applicazione o una foglia fissata ci arrivano, mentre una radice a livello di macchina è una concessione molto più grande di quanto richieda il sintomo.

Stai comunque cifrando senza una CA pubblica

La stretta di mano TLS deriva chiavi di sessione sia che il certificato del peer si concateni a qualcosa di cui ti fidi già sia che no. Auto-firmato non significa testo in chiaro, e non significa che il traffico sia leggibile in volo. Significa che il client non ha alcuna ragione a priori di credere che la chiave appartenga al server che ha richiesto.

In quello scarto vivono gli attacchi reali. Un client configurato per accettare qualsiasi certificato, tramite un’impostazione di verifica disabilitata o un pulsante “fidati comunque” premuto una volta e dimenticato, cifrerà volentieri verso chiunque risponda. L’intercettazione avviene nella fase di autenticazione, prima che i dati dell’applicazione si muovano. La cifratura senza controllo d’identità tiene fuori un osservatore passivo e fa poco altro.

Fidarsi dell’emittente non salta il controllo del nome

La validazione della catena, la corrispondenza del nome e lo scopo del certificato sono decisioni separate. Una catena può essere valida mentre il nome è sbagliato, e un nome può corrispondere mentre il certificato è stato emesso per un altro ruolo. RFC 5280 definisce i campi che portano questi vincoli, e quanto rigorosamente un client li applichi è questione di ogni applicazione.

OpenVPN rende visibile la separazione. verify-x509-name fissa il soggetto atteso tramite corrispondenza di name, name-prefix o subject. remote-cert-tls server richiede che il certificato del peer sia utilizzabile come certificato server, il che rifiuta un certificato solo client anche quando l’emittente è fidato. Nessuna delle due impostazioni viene sostituita dall’invio di un file CA.

Ispeziona il certificato prima di decidere qualsiasi cosa:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName mostra chi l’ha emesso, per quali nomi e fino a quando.
• openssl verify -CAfile ca.crt server.crt verifica se la catena che pensi di inviare convalida davvero la foglia.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funziona per endpoint TLS come un portale web; il protocollo OpenVPN sulla 1194 non è un flusso TLS semplice, quindi quel test non si applica lì.

Un certificato con data scaduta, senza subjectAltName per il nome a cui ti connetti o senza uso serverAuth fallisce indipendentemente da quanto accuratamente sia stata installata l’ancora.

Cinque controlli prima di accettarne uno

Confronta l’impronta su un canale che non sia la connessione che stai cercando di riparare: una console, un programma di installazione che hai già, un file di configurazione firmato. openssl x509 -in server.crt -noout -fingerprint -sha256 sul server e lo stesso valore nel registro del client bastano per sapere che stai guardando un solo oggetto.

Poi decidi cosa stai installando: una foglia o un’autorità che può coniarne altre. Poi decidi dove va, e nomina le applicazioni che leggono quell’archivio. Annota il percorso di rimozione finché te lo ricordi, perché fidati-e-vai-avanti è così che un’importazione temporanea diventa permanente.

Infine, pianifica il cambiamento. Un certificato o un’impronta fissati vanno aggiornati attraverso lo stesso canale fidato quando il certificato ruota, e una CA privata ha il proprio ciclo di vita di emissione e revoca. Se la chiave privata trapela, rifidarsi a una copia dello stesso certificato non ripara nulla; l’identità deve essere sostituita.

Se un avviso sopravvive a tutti e cinque i controlli, la domanda utile non è quale pulsante lo fa tacere ma quale archivio il client legge davvero e da dove veniva quella radice. Rispondi a questo, e l’importazione che stai per fare diventa una decisione invece di un riflesso.