Un certificato per un sito solo VPN: DNS-01 o CA privata?
Un sito solo VPN può avere un certificato pubblico affidabile tramite DNS-01, o uno interno da una CA privata. La scelta dipende dal nome e dai client.
Tre condizioni decidono come un sito web solo VPN debba ottenere il certificato: se controllate una zona DNS pubblica, se il nome host può comparire in registri pubblici e se a ogni client si può fornire un’ancora di fiducia privata. La via pubblica e quella privata producono entrambe un lucchetto funzionante e rispondono a domande diverse. Sceglierne una senza risolvere queste condizioni è il modo in cui un sito finisce con un certificato pubblico che non voleva, o con uno interno che metà dei client rifiuta.
Il certificato dimostra il nome; la VPN e il DNS interno forniscono il percorso.
Due vie verso un nome affidabile
Un emittente pubblico con convalida DNS-01 dimostra il controllo di un nome tramite un record TXT in una zona che controllate, così il servizio web non deve mai accettare una connessione HTTP pubblica. Una CA privata emette certificati foglia per nomi interni e distribuisce la propria ancora di fiducia tramite la gestione dei dispositivi, così nessun registro pubblico apprende il nome. Entrambe sono legittime e la scelta deriva da quelle tre condizioni, non dalla comodità. Nessuna delle due vie fornisce il percorso o la voce del resolver che serve a un client.
Un certificato pubblico pubblica anche il nome host nei registri di trasparenza dei certificati. Se il nome stesso è sensibile, quella divulgazione è una decisione di progetto e non un effetto collaterale da scoprire più tardi.
DNS-01 senza esporre il servizio
Il record di verifica è una voce TXT sotto un prefisso riservato nella zona e l’emittente la legge dal DNS autoritativo. Scegliete un client ACME e un’integrazione DNS che possano creare e rimuovere quel record, e autorizzate l’aggiornamento in modo ristretto: una credenziale API con ambito limitato per la zona, o un host controllato usato solo per la convalida. Dare al server applicativo una credenziale di registrar senza restrizioni per rinnovare un solo certificato è molta più autorità di quanta ne serva. Quando più ordini condividono un nome, tenete separati i loro valori TXT, così che la pulizia di uno non rimuova un valore che un altro ancora richiede.
Attendete la propagazione con un controllo sui server autoritativi invece di un’attesa fissa. Il comportamento di propagazione dipende dal fornitore, e un’attesa che funziona oggi non è una prova per domani.
Client gestiti e nomi deliberatamente privati
I dispositivi gestiti e i nomi deliberatamente privati si adattano bene a una CA interna. Distribuite l’emittente affidabile tramite la gestione dei dispositivi, poi emettete certificati foglia per i nomi previsti. Verificate quale archivio usa davvero ogni client, perché una singola importazione nel sistema operativo non è un’affermazione universale su ogni browser e applicazione. Il pinning della foglia è un’altra opzione dove è esplicitamente supportato, al costo di un altro aggiornamento della fiducia ogni volta che la foglia cambia.
Il canale di distribuzione conta quanto la chiave: una radice che nessuno installa non protegge nulla.
Il rinnovo fa parte del progetto
Qualunque via scegliate, il rinnovo richiede un responsabile e una procedura. Aggiornare la prova di convalida, installare il nuovo materiale e ricaricare l’ascoltatore tramite il suo meccanismo supportato sono tre passaggi distinti, e solo il primo è automatizzato dalla maggior parte dei client ACME. Un certificato che si rinnova correttamente ma non viene mai caricato produce la stessa interruzione di uno scaduto.
Il certificato non installa la rotta VPN né crea il record DNS interno. I client hanno ancora bisogno di un resolver che associ il nome all’indirizzo privato e di una rotta per raggiungerlo. Provate il sito per nome da un client che abbia entrambi.
Annotate l’emittente, il metodo di convalida, il canale di distribuzione della fiducia e il meccanismo di ricarica. Quei quattro sono il piano di rinnovo.