Perché due certificati OpenVPN possono condividere una politica CCD

Una CA può firmare due certificati che ricevono la stessa OpenVPN configurazione specifica del client, e nulla in nessuno dei due certificati avverte nessuno. I numeri di serie differiscono, le chiavi differiscono e anche i soggetti completi differiscono quando cambia un'unità organizzativa. Il server risolve la politica per client tramite un solo nome, e quel nome è l'unica cosa che deve essere univoca.

Il server risolve un nome, non un numero di serie

Con la ricerca semplice del certificato, il server prende il nome comune dal certificato presentato e cerca una voce client-config-dir con quel nome. Il numero di serie non entra mai nella ricerca. Due certificati che differiscono in ogni campo tranne il nome comune finiscono nello stesso file, così la seconda connessione eredita l'indirizzo fisso e le route inviate del primo dispositivo.

Ecco come un controllo di unicità lato CA passa mentre la VPN va ancora in collisione. I due controlli rispondono a domande diverse.

Decidete quale debba essere il nome effettivo prima di firmare qualsiasi cosa, e registratelo accanto al dispositivo o all'account a cui appartiene. Un registro di nome, proprietario, scopo e impronta del certificato copre la maggior parte delle installazioni. Senza, l'archivio dei certificati è l'unica traccia di quale nome appartenga a quale dispositivo, e quell'archivio non può distinguere una sostituzione autorizzata da un secondo dispositivo che rivendica un nome esistente. Riservate il nome all'enrollment, sotto un lock se due operatori possono emettere contemporaneamente.

Quale nome usa davvero la mappatura

La ricerca semplice del certificato usa il nome comune. Un server impostato per mappare un nome utente autenticato usa invece quel valore, il che rende il nome comune del certificato irrilevante per la scelta della politica. Leggete la configurazione in esecuzione per vedere quale mappatura è in vigore.

Entrambe le mappature possono essere presenti insieme, e allora il risultato dipende dall'ordine in cui il server le risolve. Una mappatura per nome utente che ricade sul nome comune accetterà in silenzio un certificato che il registro non ha mai approvato. Scrivete il nome effettivo accanto al comando che l'ha prodotto, così il prossimo operatore non deve riscoprire l'ordine. Testare una connessione per mappatura costa poco e risolve la questione.

Qualunque cosa produca la mappatura, è quel valore che va riservato. Riservare nomi comuni nella CA mentre il server si basa sui nomi utente riserva la cosa sbagliata.

Due CA possono approvare lo stesso nome

Un servizio VPN può fidarsi di più di un'autorità emittente, e ogni autorità ha la propria idea di quali nomi siano occupati. Due CA indipendenti possono entrambe approvare lo stesso nome comune per dispositivi diversi, e il server accetta entrambi i certificati senza lamentarsi. Inventariate ogni autorità del bundle di fiducia, non solo quella da cui emettete di solito. Il guasto compare la prima volta che si usa un certificato della seconda autorità.

Lo stesso ragionamento vale per una CA che impone l'unicità del soggetto completo anziché l'unicità del nome comune.

Due certificati che condividono un nome comune ma differiscono per unità organizzativa hanno soggetti diversi, quindi la CA non segnala alcun conflitto mentre il server vede un solo nome. Controllate l'impostazione che il vostro strumento di emissione usa davvero invece di supporre un valore predefinito. La gestione di unique_subject nella documentazione di openssl ca è la leva pertinente lì, e i wrapper attorno a quello strumento di solito la espongono invece di sostituirla.

Il rinnovo è un riuso riservato, non una collisione

Un rinnovo che conserva il nome è un riuso deliberato, e il registro dovrebbe dirlo in parole semplici. Registrate la vecchia impronta e la nuova sotto un unico nome, così un revisore può distinguere una sostituzione da una presa di controllo. L'opzione duplicate-cn del server non c'entra: governa le sessioni simultanee, non l'enrollment o le riserve di nomi. Decidete per quanto tempo entrambe le credenziali possono esistere e quando la vecchia smette di essere accettata.

Prima di consegnare la sostituzione, rileggete ciò che il certificato contiene davvero. La riga del soggetto è il campo che il server mapperà, qualunque cosa suggerisca il nome del file.

openssl x509 -in device42.crt -noout -subject -serial -issuer

La revoca identifica di norma un certificato sotto il suo emittente, quindi ritirare un numero di serie non tocca una sostituzione emessa correttamente dalla stessa autorità. Proprio questo comportamento serve a un rinnovo pulito, ed è anche per questo che la revoca non può ripulire un nome condiviso da due dispositivi. Validate il nome effettivo della politica e l'indirizzo assegnato su una connessione di prova prima che l'utente veda il dispositivo. Poi ritirate di proposito la vecchia credenziale e registrate che l'avete fatto.