Utilitzeu la CA empresarial que ja teniu per als parells d'OpenVPN

Res a OpenVPN no exigeix que el certificat provingui d'Easy-RSA, i una flota que ja té una PKI organitzativa normalment no n'hauria de construir una segona. La feina real no és triar una eina, sinó decidir què signifiquen les identitats emeses, quins parells accepta el túnel i com arriben la renovació i la revocació al verificador. Seguiu els cinc passos següents en ordre, perquè un pas posterior no pot reparar una decisió de rol presa al primer.

Emeteu dos rols en lloc d'una identitat compartida

Cada parell necessita el seu propi certificat i la clau privada corresponent. Demaneu a l'equip de PKI una identitat de servidor amb ús de servidor i identitats de client separades amb ús de client, perquè el túnel pugui distingir-les durant l'establiment de la connexió.

Resistiu els dreceres que apareixen sota pressió de terminis. Copiar la clau d'un servidor web als portàtils esborra la distinció de la qual depèn la comprovació de rol, i una clau de signatura de CA instal·lada en un extrem de VPN converteix un amfitrió compromès en una jerarquia compromesa. Un paquet PKCS12 pot portar una clau d'extrem i la seva cadena, però mai no atorga permís per reutilitzar aquesta identitat en un altre rol.

Connecteu les entrades de confiança a cada costat

El client i el servidor necessiten cadascun una àncora de confiança, la seva pròpia identitat i una expectativa de rol explícita. Un fragment de client que declari les tres coses s'assembla a això.

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

El costat del servidor ho reflecteix amb remote-cert-tls client i el seu propi certificat, i això és el que impedeix que un certificat de client sigui acceptat com a servidor. La comprovació del nom és una decisió separada de la comprovació del rol. Llegiu la configuració desplegada per veure quin camp es compara en lloc de suposar una coincidència de nom d'amfitrió a l'estil del navegador. Els dos costats també haurien de ser explícits sobre quin emissor confien, perquè un camí de fitxer compartit a tota la flota no és el mateix que una política compartida.

Lliureu intermediaris sense ampliar la confiança

Els dos costats no han de compartir una sola cadena d'emissió. Quan un parell presenta un certificat signat per un intermediari, el costat verificador necessita aquell intermediari disponible, i OpenVPN distingeix l'entrada de l'àncora de confiança dels certificats addicionals emprats per completar una cadena presentada localment. referència d'opcions TLS d'OpenVPN 2.6 documenta tots dos.

Un CA intermediari no és inherentment un problema, però una arrel empresarial àmplia abocada al paquet de confiança sí que ho és. Com més àmplia és l'àncora, més certificats superen la prova de cadena, i una comprovació de rol no ho converteix en una llista de personal autoritzat. Estrebeu l'àncora fins a l'emissor que realment signa les identitats de VPN on la jerarquia ho permeti. Si no ho permet, documenteu l'àncora més àmplia com un risc acceptat deliberadament en lloc de deixar-lo implícit.

Acordeu amb l'equip de PKI com arriben la renovació i la revocació als verificadors de VPN, incloent quins emissors importen i qui publica la llista. Un punt de distribució de CRL incrustat en un certificat és una instrucció, no una prova que algú l'hagi obtingut.

Decidiu com arriba realment la revocació

crl-verify fa que el verificador consulti un fitxer o un extrem, i aquesta disposició necessita un propietari i un camí d'actualització. Una llista copiada una sola vegada durant el desplegament deixa silenciosament de protegir-vos la primera vegada que es revoca un certificat.

Anoteu el temps de propagació esperat i proveu-lo amb un certificat que estigueu disposats a revocar. Si la llista no es pot actualitzar a l'amfitrió de VPN, l'alternativa és un període de validesa més curt més un procés de renovació que realment s'executi, no l'assumpció que la revocació funciona perquè existeix una URL.

Demostreu l'acceptació amb un client real

Connecteu un client que hauria de ser permès i confirmeu els detalls del certificat negociat al registre. Després proveu els casos que han de fallar: un certificat de client presentat com a servidor, un certificat d'un emissor fora de l'àncora de confiança i un certificat revocat si en teniu un de sobra.

Registreu l'emissor acceptat, la comprovació de rol i la font de revocació al costat del perfil. Aquest registre és el que necessitarà el proper enginyer quan un dispositiu que funcionava el mes passat deixi de connectar-se, i també és l'evidència que la CA empresarial s'utilitza dins d'una frontera d'acceptació documentada en lloc d'un abocament de confiança de propòsit general.