Usa la tua CA aziendale esistente per i peer di OpenVPN

Niente in OpenVPN richiede che il certificato provenga da Easy-RSA, e una flotta che ha già una PKI organizzativa di solito non dovrebbe costruirne una seconda. Il vero lavoro non è scegliere uno strumento, ma decidere cosa significano le identità emesse, quali peer il tunnel accetta e come il rinnovo e la revoca arrivano al verificatore. Segui i cinque passaggi qui sotto in ordine, perché un passaggio successivo non può riparare una decisione di ruolo presa nel primo.

Emetti due ruoli invece di un'unica identità condivisa

Ogni peer ha bisogno del proprio certificato e della relativa chiave privata. Chiedi al team PKI un'identità server con utilizzo server e identità client separate con utilizzo client, così che il tunnel possa distinguerle durante la stretta di mano.

Resisti alle scorciatoie che compaiono sotto la pressione delle scadenze. Una chiave di un server web copiata sui portatili cancella la distinzione su cui si basa il controllo del ruolo, e una chiave di firma CA installata su un endpoint VPN trasforma un host compromesso in una gerarchia compromessa. Un bundle PKCS12 può trasportare una chiave di endpoint e la sua catena, ma non concede mai il permesso di riutilizzare quell'identità in un altro ruolo.

Collega gli input di fiducia su ciascun lato

Il client e il server hanno bisogno ciascuno di un'ancora di fiducia, della propria identità e di un'aspettativa di ruolo esplicita. Un frammento client che dichiara tutte e tre le cose si presenta così.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Il lato server lo rispecchia con remote-cert-tls client e il proprio certificato, ed è ciò che impedisce che un certificato client venga accettato come server. Il controllo del nome è una decisione separata dal controllo del ruolo. Leggi la configurazione distribuita per vedere quale campo viene confrontato invece di presumere una corrispondenza del nome host in stile browser. Entrambi i lati dovrebbero anche essere espliciti su quale emittente si fidano, perché un percorso di file condiviso in tutta la flotta non è la stessa cosa di una politica condivisa.

Consegna gli intermediari senza ampliare la fiducia

I due lati non devono condividere un'unica catena di emissione. Quando un peer presenta un certificato firmato da un intermediario, il lato che verifica ha bisogno di quell'intermediario disponibile, e OpenVPN distingue l'input dell'ancora di fiducia dai certificati aggiuntivi usati per completare una catena presentata localmente. Il riferimento alle opzioni TLS di OpenVPN 2.6 documenta entrambi.

Una CA intermedia non è di per sé un problema, ma una radice aziendale ampia gettata nel bundle di fiducia lo è. Più ampia è l'ancora, più certificati superano il test della catena, e un controllo di ruolo non lo trasforma in un elenco di personale autorizzato. Restringi l'ancora all'emittente che effettivamente firma le identità VPN dove la gerarchia lo consente. Se non lo consente, documenta l'ancora più ampia come rischio accettato deliberatamente invece di lasciarlo implicito.

Concorda con il team PKI su come rinnovo e revoca raggiungono i verificatori VPN, inclusi quali emittenti contano e chi pubblica l'elenco. Un punto di distribuzione CRL incorporato in un certificato è un'istruzione, non la prova che qualcosa lo abbia scaricato.

Decidi come arriva realmente la revoca

crl-verify fa consultare al verificatore un file o un endpoint, e questa disposizione ha bisogno di un proprietario e di un percorso di aggiornamento. Un elenco copiato una volta durante la distribuzione smette silenziosamente di proteggerti la prima volta che un certificato viene revocato.

Annota il tempo di propagazione previsto e provalo con un certificato che sei disposto a revocare. Se l'elenco non può essere aggiornato sull'host VPN, l'alternativa è un periodo di validità più breve più un processo di rinnovo che viene davvero eseguito, non l'assunzione che la revoca funzioni perché esiste un URL.

Dimostra l'accettazione con un client reale

Connetti un client che dovrebbe essere consentito e conferma i dettagli del certificato negoziato nel registro. Poi prova i casi che devono fallire: un certificato client presentato come server, un certificato di un emittente esterno all'ancora di fiducia e un certificato revocato se ne hai uno in più.

Registra l'emittente accettato, il controllo del ruolo e la fonte di revoca accanto al profilo. Quel registro è ciò di cui ha bisogno il prossimo ingegnere quando un dispositivo che funzionava il mese scorso smette di connettersi, ed è anche la prova che la CA aziendale viene usata entro un confine di accettazione documentato invece che come discarica di fiducia generica.