OpenVPN verify-x509-name: subject, name e name-prefix

Leggete prima il tipo di corrispondenza e poi il testo: una verify-x509-name direttiva può sembrare corretta e comunque accettare un certificato di cui non volevate fidarvi. Due righe con lo stesso testo atteso ma tipi diversi sono requisiti diversi. Leggete prima il tipo, poi il testo. Trattate la direttiva come una condizione in più sulla connessione, non come l’intera verifica.

Che cosa afferma davvero l’opzione

La direttiva nomina un’identità che il certificato dell’altra parte deve portare. Quando il confronto fallisce, OpenVPN interrompe l’handshake e non sale alcun tunnel. Tutto il resto del profilo vale ancora: il certificato deve concatenarsi a una CA fidata e il controllo del ruolo deve passare, quindi è una condizione aggiuntiva e non un sostituto. Un profilo che soddisfa l’attesa del nome e fallisce il controllo del ruolo resta rotto, e il registro di solito lo dice.

È anche diversa dalla validazione del nome host che fa un browser. Il browser confronta i nomi con i nomi alternativi del subject secondo le regole del suo stack TLS, mentre OpenVPN confronta un solo campo del certificato con il tipo che avete scelto. Per questo incollare un nome host in stile browser nella direttiva può produrre una discrepanza anche quando il certificato copre davvero il servizio.

subject: l’intero nome distinto, carattere per carattere

Con subject, il valore predefinito quando non è scritto alcun tipo, il valore atteso deve riprodurre l’intero DN del subject del certificato. L’ordine dei campi, i separatori, gli spazi e l’escaping contano tutti, perché il confronto avviene sulla stringa così com’è codificata. Se omettete il tipo, avete scelto la più severa delle tre comparazioni. Non c’è alcun passo di normalizzazione che salvi una differenza cosmetica. Vale la pena saperlo prima del primo rinnovo, non dopo.

Questa severità è fragile tra un rinnovo e l’altro. Una CA che riordina gli attributi, inserisce un campo extra o cambia il modo di eseguire l’escaping di un valore produce una stringa nuova per la stessa macchina, e una direttiva che ha funzionato per anni inizia a fallire all’emissione successiva. Conservare il DN accettato nel registro delle modifiche trasforma il rinnovo successivo in una differenza. Dove l’operatore pubblica un DN completo e ne garantisce la forma, subject è una scelta ragionevole; altrove un campo più stretto è più facile da mantenere vero.

name: un solo campo, di solito il nome comune

Il tipo name confronta un solo campo del subject. Salvo diversa indicazione del profilo, quel campo è il nome comune, e il valore atteso è esattamente quel campo, non il DN che lo circonda.

La trappola è che i certificati moderni non mettono sempre il nome del servizio nel CN. Molti lo portano in un nome alternativo del subject e lasciano il CN vuoto o generico, così un certificato che un browser accetta può comunque fallire questo confronto. Esaminate il certificato che vi è stato realmente emesso prima di scrivere l’attesa e confermate quale campo seleziona il profilo. Un CN vuoto confrontato con un nome è una discrepanza, non un incidente di configurazione.

name-prefix: ampio per concezione, quindi delimitatelo

Un’attesa di tipo name-prefix corrisponde all’inizio del campo selezionato. È comodo per uno schema di denominazione e pericoloso per qualsiasi cosa condivisa.

Con vpn.example come attesa, sia vpn.example.com sia vpn.example.net passerebbero, purché il resto della catena sia fidato. L’ampiezza è la funzione, ed è anche la parte da giustificare per iscritto. Un prefisso è ragionevole quando la CA e lo schema di denominazione sono vostri, e molto più debole quando una CA pubblica emette nello stesso modello. Se lo schema ha bisogno di flessibilità, limitatelo nella CA invece di ampliare il controllo del client.

Scegliete il tipo dall’identificatore, poi dimostratelo

Lavorate a ritroso dall’identità che l’operatore intende. Se pubblica un DN completo e lo mantiene stabile, subject lo esprime. Se nomina il servizio con il nome comune, usate name. Se possiede uno schema di denominazione e ne accetta tutto lo spazio, name-prefix lo dice esplicitamente.

I rinnovi sono il momento in cui la direttiva viene messa alla prova. Confrontate l’identità approvata con il certificato nuovo invece che con il vecchio file, perché un nuovo indirizzo di endpoint non implica una nuova identità del certificato. Non cancellate la direttiva solo perché un indirizzo familiare risponde: la raggiungibilità e la controparte prevista sono fatti diversi, e l’indirizzo dimostra solo che qualcosa ha risposto. Annotate l’errore esatto e i dettagli pubblici del nome in un rapporto ripulito, perché una discrepanza di nome può essere mostrata senza alcun materiale di chiave privata.

Dopo una correzione supportata, riconnettetevi con tutti i controlli previsti attivi e verificate la risorsa che vi serve davvero. Il successo significa che il server previsto è stato accettato, non che un certificato sia stato forzato. Il manuale ufficiale OpenVPN 2.6 manual documenta i tre tipi e le loro note di fiducia, ed è il riferimento da citare quando un’interfaccia del fornitore è in disaccordo con il profilo.