Due certificati OpenVPN, un solo nome CCD: cosa è andato storto

Due certificati client con numeri di serie diversi, chiavi diverse e persino soggetti completi diversi possono comunque finire nello stesso file di criteri, perché il server non guarda nulla di tutto ciò. Legge un nome dal certificato e apre il file di configurazione client corrispondente. Se entrambi i certificati portano lo stesso nome, il secondo eredita i criteri del primo nel momento in cui si connette.

La collisione nasce all'iscrizione e si scopre solo al momento della connessione, di solito quando un dispositivo riceve un indirizzo o un insieme di route che appartengono a un'altra macchina. Prevenirla significa concordare quale campo il server mappa, poi prenotare quel valore prima che qualsiasi cosa venga firmata.

I tuoi strumenti per i certificati non ti avviseranno, perché l'unicità all'interno di X.509 e l'unicità di un nome di criterio OpenVPN sono requisiti diversi applicati da sistemi diversi.

Il server cerca un nome, non un'impronta

Con la consueta mappatura basata sui certificati, il server prende il nome comune dal certificato presentato e cerca un file con quel nome nella sua directory di configurazione client. Quel file può fissare un indirizzo statico, spingere route o applicare marcature firewall per client. La ricerca è una corrispondenza di stringa con un nome di file, quindi maiuscole, spazi e punteggiatura contano tutti.

Alcune installazioni invertono deliberatamente la mappatura affinché un nome utente autenticato prenda il posto del nome comune, e allora è il nome utente a dover essere unico. In ogni caso, il valore che seleziona i criteri è il valore che prenoti. Decidi quale sia prima di emettere qualsiasi cosa; indovinare dopo una collisione costa più che chiedere.

Dove due autorità coincidono sullo stesso nome

Un'organizzazione che accetta certificati da più di un'autorità emittente gestisce due processi di iscrizione indipendenti che scrivono in un unico spazio dei nomi. Le regole di unicità di ciascuna autorità valgono al suo interno, quindi entrambe possono emettere legittimamente per lo stesso nome comune senza che nessuna noti qualcosa di sbagliato.

I numeri di serie non aiutano. X.509 richiede che un numero di serie sia unico nell'ambito del suo emittente, il che è una proprietà della contabilità di quell'autorità e non un'identità globale del dispositivo. Anche il controllo del soggetto è un test diverso da quello del nome comune: due certificati possono condividere un CN ma differire nell'unità organizzativa e quindi portare soggetti distinti. Tutte queste proprietà possono valere mentre il server mappa comunque entrambi i certificati su un solo nome di file.

La documentazione di OpenSSL CA copre l'impostazione unique_subject che governa il parere del suo stesso database, e il punto di partenza onesto è leggere la propria configurazione di emissione invece di presumere che si applichi un certo valore predefinito di EasyRSA o OpenSSL.

Prenota il nome effettivo prima di firmare

Tieni un registro che mappa un dispositivo al suo record approvato e da lì a un nome di file di criteri esatto, così che un nome venga allocato una volta e resti allocato. La prenotazione deve essere atomica, il che in pratica significa un vincolo di database o un lock attorno al passo alloca-poi-firma, non un foglio di calcolo modificato da due persone.

Poi rendi il controllo parte dell'emissione: rifiuta di firmare quando il nome richiesto esiste già e includi in quel controllo ogni autorità di cui il server si fida, perché un nome prenotato dall'altra autorità è altrettanto occupato. Una richiesta rifiutata con un motivo chiaro costa meno di un ticket su un dispositivo che continua a ricevere l'indirizzo statico di qualcun altro.

Il rinnovo riutilizza un nome di proposito

La riemissione per un dispositivo esistente dovrebbe produrre un nuovo numero di serie sotto lo stesso nome di criterio, e questo è un riutilizzo legittimo e non una collisione. Ciò che va deciso in anticipo è la sovrapposizione: se i certificati vecchio e nuovo possono essere validi contemporaneamente, e come viene ritirata la vecchia credenziale.

Non ricorrere a duplicate-cn per risolvere questo. Quell'opzione del server governa le connessioni simultanee che presentano lo stesso nome; non blocca l'iscrizione, e abilitarla non rende un indirizzo statico condiviso sicuro per due macchine contemporaneamente. La revoca normalmente identifica un certificato tramite emittente e numero di serie, quindi ritirare la vecchia credenziale non deve invalidarne il sostituto purché il server riceva e applichi i dati di revoca corretti.

Conferma la mappatura con gli strumenti sulla macchina

Prima di consegnare a un dispositivo la sua nuova credenziale, leggi il nome dal certificato come farà il server, poi confrontalo con il file di criteri che ti aspetti venga scelto.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

Il primo comando stampa i campi del soggetto separatamente, il che rende subito visibile un'unità organizzativa fuori posto o uno spazio doppio. Il secondo conferma che esiste un file di criteri esattamente con quel nome, e il terzo mostra se il server è configurato per consentire più sessioni su un solo nome. Esegui tutti e tre su un certificato nuovo prima che lasci la fase di iscrizione, finché un errore costa ancora una firma invece di un incidente. Conserva l'output con il ticket così la persona successiva vede quale nome il server ha realmente ricevuto.

Termina con una connessione reale e confronta l'indirizzo assegnato e le route spinte con il file di criteri, e non con ciò che pensavi di scrivere. Se due dispositivi riportano lo stesso indirizzo statico, il registro ha una collisione che nessuna ispezione dei certificati rivelerà mai.