Use su CA empresarial existente para los pares de OpenVPN

Nada en OpenVPN exige que el certificado provenga de Easy-RSA, y una flota que ya tiene una PKI organizativa normalmente no debería construir una segunda. El trabajo real no es elegir una herramienta, sino decidir qué significan las identidades emitidas, qué pares acepta el túnel y cómo llegan la renovación y la revocación al verificador. Recorra los cinco pasos siguientes en orden, porque un paso posterior no puede reparar una decisión de rol tomada en el primero.

Emita dos roles en lugar de una identidad compartida

Cada par necesita su propio certificado y su clave privada correspondiente. Pida al equipo de PKI una identidad de servidor con uso de servidor e identidades de cliente separadas con uso de cliente, para que el túnel pueda distinguir ambas durante el protocolo de enlace.

Resista los atajos que aparecen bajo la presión de los plazos. Una clave de servidor web copiada a portátiles borra la distinción de la que depende la comprobación de rol, y una clave de firma de CA instalada en un extremo de VPN convierte un host comprometido en una jerarquía comprometida. Un paquete PKCS12 puede llevar una clave de extremo y su cadena, pero nunca concede permiso para reutilizar esa identidad en otro rol.

Conecte las entradas de confianza en cada lado

El cliente y el servidor necesitan cada uno un ancla de confianza, su propia identidad y una expectativa de rol explícita. Un fragmento de cliente que declare las tres cosas se parece a esto.

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 lado del servidor lo refleja con remote-cert-tls client y su propio certificado, y eso es lo que impide que un certificado de cliente se acepte como servidor. La comprobación del nombre es una decisión separada de la comprobación de rol. Lea la configuración desplegada para ver qué campo se compara en lugar de suponer una coincidencia de nombre de host al estilo del navegador. Ambos lados también deberían ser explícitos sobre en qué emisor confían, porque una ruta de archivo compartida en toda la flota no es lo mismo que una política compartida.

Entregue intermedios sin ampliar la confianza

Los dos lados no tienen que compartir una sola cadena de emisión. Cuando un par presenta un certificado firmado por un intermedio, el lado verificador necesita ese intermedio disponible, y OpenVPN distingue la entrada del ancla de confianza de los certificados adicionales usados para completar una cadena presentada localmente. La referencia de opciones TLS de OpenVPN 2.6 documenta ambas.

Una CA intermedia no es un problema en sí misma, pero una raíz empresarial amplia arrojada al paquete de confianza sí lo es. Cuanto más amplio es el ancla, más certificados superan la prueba de cadena, y una comprobación de rol no convierte eso en una lista de personal autorizado. Estreche el ancla hasta el emisor que realmente firma las identidades de VPN donde la jerarquía lo permita. Si no lo permite, documente el ancla más amplia como un riesgo aceptado deliberadamente en lugar de dejarlo implícito.

Acuerde con el equipo de PKI cómo llegan la renovación y la revocación a los verificadores de VPN, incluidos qué emisores importan y quién publica la lista. Un punto de distribución de CRL incrustado en un certificado es una instrucción, no una prueba de que algo lo haya obtenido.

Decida cómo llega realmente la revocación

crl-verify hace que el verificador consulte un archivo o un extremo, y esa disposición necesita un propietario y una ruta de actualización. Una lista copiada una sola vez durante el despliegue deja silenciosamente de protegerle la primera vez que se revoca un certificado.

Anote el tiempo de propagación esperado y pruébelo con un certificado que esté dispuesto a revocar. Si la lista no se puede actualizar en el host de VPN, la alternativa es un periodo de validez más corto más un proceso de renovación que realmente se ejecute, no suponer que la revocación funciona porque existe una URL.

Demuestre la aceptación con un cliente real

Conecte un cliente que debería ser permitido y confirme los detalles del certificado negociado en el registro. Luego pruebe los casos que deben fallar: un certificado de cliente presentado como servidor, un certificado de un emisor fuera del ancla de confianza y un certificado revocado si tiene uno de sobra.

Registre el emisor aceptado, la comprobación de rol y la fuente de revocación junto al perfil. Ese registro es lo que el siguiente ingeniero necesita cuando un dispositivo que funcionaba el mes pasado deja de conectarse, y también es la evidencia de que la CA empresarial se usa dentro de un límite de aceptación documentado en lugar de como un vertedero de confianza de propósito general.