Autofirmato o CA pubblica per una VPN: cosa cambia davvero

Arrivi alla pagina dei certificati di una configurazione VPN, vedi un'opzione autofirmata gratuita accanto a una CA pubblica a pagamento, e la domanda suona come una scelta di sicurezza. In realtà è una scelta di pubblico. Entrambe le opzioni cifrano il tunnel con le stesse primitive, ed entrambe diventano inutili se la chiave privata trapela. Ciò che le separa è chi formula l'affermazione sull'identità del server e chi è in grado di verificare quell'affermazione.

Un certificato svolge due compiti che vengono confusi

Un certificato lega una chiave pubblica a un nome, e la chiave svolge il lavoro di cifratura e firma. La firma sul certificato è una dichiarazione separata: un'autorità ha verificato che il nome appartiene a questo titolare della chiave. Un certificato autofirmato fa questa dichiarazione su se stesso, il che non è affatto un'affermazione di terze parti.

I siti web pubblici hanno bisogno della versione di terze parti, perché i visitatori arrivano senza alcuna relazione precedente e si affidano all'archivio di fiducia del browser. Un client VPN non è un estraneo. Gli dai il certificato della CA, oppure appunti il certificato del server, dentro il profilo che installa, così la verifica avviene esattamente contro l'autorità che hai scelto. Nessuna CA commerciale deve essere coinvolta perché quel controllo significhi qualcosa.

La forza della sessione risultante deriva dalla dimensione della chiave e dalla suite di cifratura, non dal firmatario. Per questo definire un certificato autofirmato "meno cifrato" è semplicemente sbagliato; è meno ampiamente garantito, che è una proprietà diversa.

Dove una CA pubblica guadagna il suo compenso

Il caso più chiaro è la pagina di amministrazione. Se colleghi, appaltatori o chiunque altro senza un profilo preparato devono aprire l'interfaccia web del server VPN senza un avviso del browser, un certificato pubblicamente attendibile elimina quell'attrito. Il browser si fida già del firmatario, quindi non c'è nulla da importare e nulla da spiegare.

Quella comodità ha costi che vale la pena nominare prima di acquistare. Il rinnovo deve essere automatizzato, altrimenti il sito si rompe secondo un calendario, i certificati pubblici espongono il nome host nei registri di trasparenza dei certificati, e i limiti di velocità di emissione puniscono uno script che riprova troppo avidamente. Nessuno di questi è un motivo per evitare una CA pubblica, ma è lavoro operativo che una CA privata sposta altrove.

Ciò che un certificato pubblico non fa è autenticare i tuoi utenti. L'identità del client è una decisione separata, presa con certificati client, password o un secondo fattore, e la CA che firma il server non dice nulla su chi può connettersi ad esso.

Dove una CA privata si adatta a una VPN

Per una VPN privata con un insieme noto di client, gestire una propria CA è la scelta convenzionale. Crei la CA una volta, firmi il certificato del server con un nome che i client useranno, e distribuisci il certificato della CA dentro ogni profilo. Ogni client verifica quindi il server contro la tua autorità, e nessuna parte esterna apprende il nome host.

I costi sono reali ma limitati. I browser avviseranno quando qualcuno apre la pagina di amministrazione direttamente, perché il browser non ha motivo di fidarsi della tua CA. La distribuzione dei profili diventa parte dell'onboarding, e ruotare la CA significa toccare ogni client. Sono prezzi accettabili per un servizio con dieci o cinquanta utenti noti e dolorosi per un endpoint pubblico con migliaia.

Una condizione rende valido l'intero assetto: la verifica deve avvenire. Un client configurato per ignorare gli errori dei certificati accetta qualsiasi server che presenti qualsiasi certificato, quindi la garanzia di identità scompare mentre la cifratura resta. Quell'impostazione è la vera debolezza nella maggior parte delle storie di "autofirmato è insicuro".

La chiave privata della CA decide cosa potrai fare dopo

La sorpresa di solito arriva mesi dopo, quando vuoi aggiungere un dispositivo. Emettere un certificato client richiede la chiave privata della CA, e così produrre una lista di revoca. Se hai ereditato un server che ha i file del certificato e della chiave ma non la chiave della CA, non puoi firmare nulla di nuovo. Le tue opzioni sono ricostruire la PKI e consegnare a ogni client un nuovo certificato CA, oppure passare all'autenticazione con password, che è un modello di sicurezza diverso e non ripristina ciò che è andato perso.

Due trappole più piccole vivono nello stesso territorio. Gli script easy-rsa presumono che tu sia nella directory che li contiene, quindi un errore di file mancante di solito significa la posizione sbagliata e non un'installazione danneggiata. E un progetto solo con certificati è del tutto legittimo: puoi richiedere certificati client senza una chiave precondivisa, purché ogni client ne abbia uno e il server verifichi la catena.

Emetti un certificato per dispositivo invece di un unico certificato client condiviso per tutto il team. Un portatile smarrito ti costa allora una sola revoca invece di una riemissione per tutti.

Controlla cosa hai ereditato

Prima di pianificare qualsiasi modifica, leggi il certificato che hai già:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Se l'emittente è uguale al soggetto, il certificato è autofirmato, il che è una scelta di progettazione e non un difetto. Le date ti dicono quando il rinnovo diventerà il problema di qualcuno, e una verifica riuscita contro la CA che intendi distribuire conferma che la catena funziona prima che un solo client la provi.

Poi scegli per pubblico e distribuzione: CA pubblica quando browser sconosciuti devono fidarsi della pagina di amministrazione, CA privata quando ogni client riceve un profilo che controlli. Nessuna delle due risposte è più cifrata dell'altra.