Tenere la chiave di firma della CA di OpenVPN fuori da /etc/openvpn

Due directory che in un tutorial sembrano uguali svolgono compiti completamente diversi. Una contiene l’autorità di certificazione: la sua chiave privata, il contatore dei numeri di serie e il registro di tutto ciò che ha firmato. L’altra contiene ciò che il demone deve avere per avviarsi e servire i client. Metterle entrambe sullo stesso host sotto lo stesso account è comodo per un pomeriggio e costoso per il resto della vita della distribuzione, perché il demone finisce accanto all’unica chiave in grado di creare qualsiasi identità desideri.

Cosa contiene l’area di lavoro della CA

Una directory PKI è stato dell’emittente, non configurazione. Contiene la chiave privata e il certificato della CA, un file del numero di serie, un indice dei certificati emessi e il materiale per identità che ne è stato prodotto.

Firmare una richiesta cambia quello stato, ed è per questo che l’area di lavoro appartiene a un account controllato dall’amministratore su un host dove il servizio VPN non viene eseguito. Chiunque possa leggere la chiave privata della CA può emettere un certificato di cui il server si fiderà, quindi la protezione della chiave è l’intero modello di fiducia in un solo file. Copiarla in una seconda posizione per risparmiare un passaggio crea una seconda cosa da proteggere e una seconda cosa da dimenticare. Ogni firma incrementa anche il numero di serie e aggiunge una voce all’indice, ed è per questo che l’area di lavoro è una copia di stato e non una cartella di file.

Il certificato pubblico della CA è diverso. È destinato a essere distribuito, ed è ciò che client e server usano per verificarsi a vicenda.

Cosa legge il demone all’avvio

Un server in esecuzione consuma un insieme ridotto: il proprio certificato, la propria chiave privata, il certificato della CA per verificare i peer e il materiale di chiavi richiesto dalla modalità scelta. Legge quei percorsi all’avvio e di nuovo al ricaricamento.

La proprietà va valutata rispetto all’unità che si avvia davvero, non rispetto a una shell root interattiva. Il sandboxing dichiarato può rendere parte del filesystem in sola lettura o invisibile anche quando un test manuale come root riesce.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

La terza riga è quella che la gente salta. Chiede all’account del demone stesso se può leggere la chiave, ed è l’unica versione della domanda che conta una volta ceduti i privilegi. Un’uscita zero come root non dice nulla su ciò che accade dopo la cessione.

Vale la pena separare i due percorsi di guasto prima di cambiare qualsiasi permesso. Un guasto di firma punta alla directory PKI, al permesso di ricerca sulle sue directory superiori e all’account che esegue l’emittente. Un guasto di avvio punta all’unità, alla sua directory di lavoro e ai percorsi indicati nella configurazione del server. Rendere tutto l’albero leggibile a tutti non risolve nessuno dei due e rimuove il confine da cui entrambi dipendono.

Perché copiare la chiave della CA sul server fallisce più tardi

La copia di solito inizia come mossa di debug: qualcuno vuole rinnovare un client sull’host VPN, così la chiave della CA finisce in /etc/openvpn e il rinnovo funziona. L’attività immediata riesce e il confine è sparito.

Poi il server viene salvato, e l’autorità di firma entra nei backup. Un’istantanea, un pacchetto di supporto o una copia della directory di configurazione ora porta con sé la capacità di emettere identità fidate finché la CA è valida. Chi possiede quella copia può creare un certificato per qualsiasi nome accettato dal server, compresi nomi mai emessi. L’unica registrazione di quell’emissione è quella che scelgono di conservare.

Riprendersi da quello stato non è questione di cancellare un file. Bisogna decidere se la chiave è stata esposta, ruotare la CA se lo è stata e ridistribuire la fiducia a ogni peer. Un’area di lavoro separata evita tutta la conversazione.

Account, directory, backup

Date all’emittente un proprio account e una propria home, tenuti fuori dall’host VPN quando è pratico. Date al demone un account diverso, con accesso in lettura al materiale distribuito e accesso in scrittura a nulla che emetta certificati. Distribuite copiando i certificati pubblici verso l’esterno e mai tirando lo stato privato dell’emittente verso l’interno. Salvate i due ruoli separatamente, perché la loro sensibilità e le loro storie di ripristino differiscono.

Dopo una revoca, aggiornate il file CRL indicato dalla configurazione del server, poi ricaricate il servizio perché le nuove connessioni lo leggano. La documentazione di Easy-RSA copre la struttura dell’area di lavoro e il flusso di firma; le regole di proprietà attorno ad essa restano una decisione sul vostro host. Verificate cosa ha caricato il servizio con openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate invece di dare per scontato che il ricaricamento l’abbia raccolto.

Un test che dimostra la separazione

Verificate il caso negativo, non solo quello funzionante. Firmate un certificato dall’account dell’emittente come previsto, poi confermate che lo stesso account non può avviare il servizio né leggere la chiave privata del server. Poi confermate che l’account del demone non può leggere la chiave privata della CA.

Quei tre controlli richiedono pochi minuti e sopravvivono ai cambi di personale, perché sono affermazioni sui permessi e non sulle abitudini. Scrivete il risultato con i percorsi e gli account coperti, più la data in cui li avete eseguiti. La prossima persona che erediterà questa distribuzione altrimenti ricaverà di nuovo il confine da un tutorial che non ne ha mai avuto uno. Un registro datato è anche ciò che fa durare la prossima revisione pochi minuti invece di un pomeriggio.