¿Puede funcionar un certificado RSA con dh none en OpenVPN?

Aquí hay una configuración de servidor que dice dh none junto a un certificado que dice RSA, además de la incómoda sospecha de que uno de los dos debe estar mal. Nada está mal. El certificado firma y autentica; el intercambio de claves establece un secreto compartido. Son dos tareas distintas en el mismo handshake, y TLS permite que un certificado RSA autentique un handshake que usa un acuerdo efímero sobre curva elíptica.

La confusión suele llegar con una guía de migración. Dice que se sustituya el archivo de parámetros DH por dh none, el lector nota que el certificado no es un certificado de curva elíptica, y ambos hechos se tratan como una contradicción.

Por qué los dos ajustes parecen relacionados

La configuración antigua de OpenVPN pedía un archivo de parámetros DH porque Diffie-Hellman de campo finito necesita parámetros de dominio en los que ambas partes coincidan. La directiva dh apuntaba a ese archivo. Cuando un despliegue pasa a ECDH, los parámetros provienen de una curva con nombre en su lugar, y el archivo ya no hace falta, que es lo que expresa dh none.

Los certificados son un eje aparte. Llevan una clave pública y una firma que prueban la identidad del servidor, y esa clave puede ser RSA o de curva elíptica sin importar cómo se acuerde la clave de sesión. Un handshake que usa ECDHE para el acuerdo de clave y RSA para la autenticación es habitual y está ampliamente desplegado.

La nomenclatura empeora el solapamiento. La curva elíptica aparece tanto en los nombres de suite ECDHE como ECDSA, así que es fácil suponer que cualquier conexión que mencione una curva debe incluir un certificado de curva. No es así.

Cómo leer correctamente un nombre de suite TLS 1.2

Tome ECDHE-RSA-AES256-GCM-SHA384. El primer token es la familia de intercambio de claves: Diffie-Hellman efímero sobre curva elíptica. El segundo es la familia de autenticación: RSA. El resto describe la protección de registros y el hash usado en el handshake.

Una suite ECDHE-ECDSA usa la misma familia de intercambio de claves con un método de autenticación distinto, así que necesita un certificado de curva elíptica. Una suite DHE-RSA usa Diffie-Hellman efímero de campo finito con autenticación RSA, y esa sí necesita parámetros DH.

Lea un nombre de suite de izquierda a derecha y asigne cada parte a su tarea. Una vez separados los tokens, la pregunta cambia de «mi certificado coincide con dh none» a «mi servidor permite una suite cuyo intercambio de claves no necesita un archivo DH».

Qué desactiva realmente dh none

dh none indica al servidor que no cargue un archivo de parámetros DH de campo finito. No desactiva la autenticación, la validación de certificados ni el propio TLS. Lo que sí exige es que el intercambio de claves negociado sea uno que no necesite esos parámetros, lo que en la práctica significa una suite ECDHE o un handshake TLS 1.3.

De ese requisito viene la rotura. Si la política de cifrados TLS del servidor se limita a suites DHE, o si un cliente solo ofrece esas, eliminar el archivo de parámetros no deja ningún método de intercambio de claves utilizable y el handshake falla. El error suele aparecer durante el handshake del canal de control, antes de cualquier autenticación de usuario. Lea la lista de cifrados antes de culpar al archivo que falta.

Del lado de la curva elíptica, la curva la elige la configuración TLS del servidor, y OpenVPN ofrece una opción para elegirla en ramas antiguas. TLS 1.3 gestiona la negociación del grupo dentro del protocolo y no consulta el archivo DH en absoluto.

dh none no es una rebaja de seguridad por sí mismo. La fuerza del intercambio depende entonces de la curva y la suite que realmente se negocien, por eso el siguiente paso es mirar qué eligieron los pares y no el archivo que falta.

Confirmar la negociación antes de editar

Suba la verbosidad del servidor y del cliente y lea la línea del canal de control que OpenVPN imprime tras una conexión. Nombra la versión de TLS y el cifrado negociado, e informa del tipo de clave del certificado del par. Esa única línea responde a la pregunta que el archivo de configuración solo insinúa.

Si muestra TLS 1.2 con una suite ECDHE-RSA y un certificado RSA, la combinación es exactamente lo que dh none espera, y no hay nada que reparar. Si muestra una suite DHE o un fallo de handshake sin cifrado común, el arreglo está en la política de cifrados o en la capacidad del cliente, no en el certificado.

Pruebe el cliente más antiguo que pretenda soportar, porque un cliente actual puede negociar TLS 1.3 mientras uno más antiguo se limita a suites TLS 1.2. Si el cliente más antiguo no tiene solapamiento, amplíe las suites permitidas o actualice ese extremo.

No desactive la verificación de certificados para superar un fallo de handshake. El fallo le dice que los pares no pudieron acordar un intercambio de claves, y desactivar la comprobación elimina la garantía de identidad sin resolver el acuerdo.

Lista de comprobación: ¿el certificado es RSA, se permite una suite ECDHE, el registro muestra esa suite y el cliente compatible más antiguo también la negocia? Si las cuatro son sí, dh none hace su trabajo.