Use a súa CA empresarial existente para os pares de OpenVPN

Nada en OpenVPN esixe que o certificado proveña de Easy-RSA, e unha frota que xa ten unha PKI organizativa normalmente non debería construír unha segunda. O traballo real non é escoller unha ferramenta, senón decidir que significan as identidades emitidas, que pares acepta o túnel e como chegan a renovación e a revocación ao verificador. Percorra os cinco pasos seguintes en orde, porque un paso posterior non pode reparar unha decisión de rol tomada no primeiro.

Emita dous roles en lugar dunha identidade compartida

Cada par necesita o seu propio certificado e a súa clave privada correspondente. Pida ao equipo de PKI unha identidade de servidor con uso de servidor e identidades de cliente separadas con uso de cliente, para que o túnel poida distinguir ambas durante o protocolo de enlace.

Resista os atallos que aparecen baixo a presión dos prazos. Unha clave de servidor web copiada a portátiles borra a distinción da que depende a comprobación de rol, e unha clave de sinatura de CA instalada nun extremo de VPN converte un host comprometido nunha xerarquía comprometida. Un paquete PKCS12 pode levar unha clave de extremo e a súa cadea, pero nunca concede permiso para reutilizar esa identidade noutro rol.

Conecte as entradas de confianza en cada lado

O cliente e o servidor necesitan cada un unha áncora de confianza, a súa propia identidade e unha expectativa de rol explícita. Un fragmento de cliente que declare as tres cousas parécese a isto.

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

O lado do servidor reflícteo con remote-cert-tls client e o seu propio certificado, e iso é o que impide que un certificado de cliente se acepte como servidor. A comprobación do nome é unha decisión separada da comprobación de rol. Lea a configuración despregada para ver que campo se compara en lugar de supor unha coincidencia de nome de host ao estilo do navegador. Ambos os dous lados deberían ser explícitos sobre en que emisor confían, porque unha ruta de ficheiro compartida en toda a frota non é o mesmo que unha política compartida.

Entregue intermedios sen ampliar a confianza

Os dous lados non teñen que compartir unha soa cadea de emisión. Cando un par presenta un certificado asinado por un intermedio, o lado verificador necesita ese intermedio dispoñible, e OpenVPN distingue a entrada da áncora de confianza dos certificados adicionais usados para completar unha cadea presentada localmente. A referencia de opcións TLS de OpenVPN 2.6 documenta ambas.

Unha CA intermedia non é un problema en si mesma, pero unha raíz empresarial ampla botada ao paquete de confianza si o é. Canto máis ampla é a áncora, máis certificados superan a proba de cadea, e unha comprobación de rol non converte iso nunha lista de persoal autorizado. Estreite a áncora ata o emisor que realmente asina as identidades de VPN onde a xerarquía o permita. Se non o permite, documente a áncora máis ampla como un risco aceptado deliberadamente en lugar de deixalo implícito.

Acorde co equipo de PKI como chegan a renovación e a revocación aos verificadores de VPN, incluídos que emisores importan e quen publica a lista. Un punto de distribución de CRL incrustado nun certificado é unha instrución, non unha proba de que algo o obtivese.

Decida como chega realmente a revocación

crl-verify fai que o verificador consulte un ficheiro ou un extremo, e esa disposición necesita un propietario e unha ruta de actualización. Unha lista copiada unha soa vez durante o despregamento deixa silenciosamente de protexelo a primeira vez que se revoga un certificado.

Anote o tempo de propagación esperado e probéao cun certificado que estea disposto a revogar. Se a lista non se pode actualizar no host de VPN, a alternativa é un período de validez máis curto máis un proceso de renovación que realmente se execute, non supoñer que a revocación funciona porque existe unha URL.

Demostre a aceptación cun cliente real

Conecte un cliente que debería ser permitido e confirme os detalles do certificado negociado no rexistro. Logo probe os casos que deben fallar: un certificado de cliente presentado como servidor, un certificado dun emisor fóra da áncora de confianza e un certificado revogado se ten un de sobra.

Rexiste o emisor aceptado, a comprobación de rol e a fonte de revocación xunto ao perfil. Ese rexistro é o que o próximo enxeñeiro necesita cando un dispositivo que funcionaba o mes pasado deixa de conectarse, e tamén é a evidencia de que a CA empresarial se usa dentro dun límite de aceptación documentado en lugar de como un vertedoiro de confianza de propósito xeral.