SECLEVEL=0 cura el síntoma, no el certificado

Una conexión de OpenVPN falla, alguien encuentra un arreglo de una línea que añade SECLEVEL=0 y el túnel se levanta. Lo que cambió no fue el certificado ni el conjunto de cifrados; se movió un umbral de aceptación en toda la biblioteca, y todo lo que el proceso hace después hereda el nuevo límite. Merece la pena entenderlo antes de que la misma línea se copie en cada perfil del entorno.

Determine qué biblioteca y qué política están en vigor

SECLEVEL es un concepto de OpenSSL, así que la primera pregunta es si su compilación usa OpenSSL siquiera. OpenVPN puede enlazarse con más de una biblioteca criptográfica, y un ajuste que se aplica a una de ellas no tiene sentido para las demás. Pregunte al binario con qué se construyó y después pregunte a la biblioteca qué versión y configuración cargó:

openvpn --version | head -3
openssl version -a

Lea la salida de la versión con atención, porque las distribuciones parchean los valores predeterminados. Algunas incluyen una configuración del sistema que eleva el nivel mínimo por encima del predeterminado de upstream, y por eso el mismo perfil se comporta de forma distinta en dos máquinas con paquetes OpenVPN idénticos. La política efectiva es la que cargó el proceso en ejecución, no la del manual de upstream.

Después separe las dos capas que la gente confunde. OpenVPN tiene sus propios controles TLS, incluidos un ajuste de perfil de certificado y listas explícitas de cifrados, y estos se sitúan por encima de lo que impone la biblioteca. Bajar el nivel de la biblioteca no cambia qué cifrados enumera su configuración de OpenVPN, y estrechar la lista de OpenVPN no eleva el umbral de la biblioteca. Saber qué capa le rechazó es lo que impide que el arreglo sea una conjetura.

Separe las tres cosas que pueden rechazarse

El primer candidato es material de identidad: un certificado cuya clave es demasiado pequeña o cuyo algoritmo de firma la política ya no acepta. El segundo es un parámetro de intercambio de claves, como un grupo que la política considera demasiado débil. El tercero es un conjunto de cifrados que la política excluye. Los tres pueden producir un fallo de handshake, y solo el texto del error y la etapa de negociación los distinguen.

Ninguno de esos tres es el cifrado del canal de datos. OpenVPN negocia el cifrado del túnel por separado del handshake TLS, así que una conexión que tiene éxito tras un cambio de nivel de seguridad no dice nada sobre qué cifrado protege sus datos. Si la pregunta que plantea en realidad es sobre la confidencialidad de los datos, está mirando el dial equivocado.

Bajar el nivel amplía la aceptación de las tres entradas a la vez. Esa es la parte que la gente pasa por alto: el arreglo que admite un certificado antiguo también admite un grupo débil y un conjunto que quizá no pretendía permitir. Un solo error provocó el cambio, y el cambio es más amplio que el error. Esa asimetría es la razón por la que una excepción acotada es mejor que un valor predeterminado para todo el entorno.

Cambie la entrada, no el umbral

Conserve el error exacto antes de tocar la configuración, incluida la etapa que lo informó y el objeto que nombró. Un problema de certificado se resuelve sustituyendo el certificado por algo que la política actual acepte, lo que normalmente significa reemitirlo en la autoridad en lugar de reinstalar el mismo archivo.

Si la entrada rechazada pertenece a un par que usted no controla, la conversación es con el propietario de ese par sobre material de sustitución admitido. Bajar su propio umbral para acomodar un sistema que nadie mantiene traslada el coste de ellos a todos los que se conectan después.

Donde el servidor aplica la política, compruebe si un ajuste a nivel de OpenVPN es la causa real antes de culpar a la biblioteca. Un perfil de certificado que exige una clase más estricta de la que el certificado desplegado puede satisfacer fallará sin importar el nivel de seguridad, y eliminar ese perfil es un cambio más estrecho que desactivar las comprobaciones de la biblioteca.

Si debe bajarlo, acótelo y documéntelo

A veces una excepción de compatibilidad aprobada es la respuesta correcta, sobre todo para un par heredado con un plan de retirada con fecha. Acótela al servicio que la necesita en lugar de a todo el host: un archivo de configuración por servicio o una configuración OpenSSL dedicada tiene un radio de impacto menor que una exportación en el perfil global.

Anote cuatro cosas con la excepción: el ajuste exacto, el propietario que la aprobó, los clientes afectados y la condición bajo la cual se retira. Una excepción sin condición de retirada es un debilitamiento permanente con una justificación temporal adjunta.

La reversión debería ser un solo paso que ya haya probado. Conserve la configuración anterior, aplique el cambio, confirme que el servicio arranca y sepa exactamente qué archivo restaurar si la siguiente conexión se comporta de forma distinta a la esperada.

Verifique la identidad y la protección después

Una conexión correcta solo demuestra que las condiciones revisadas la admitieron. Confirme que la verificación del nombre de host y del par sigue haciendo su trabajo, que el certificado en uso es el que pretendía desplegar y que el canal de datos negociado coincide con la política que cree tener.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

La referencia de niveles de seguridad de OpenSSL es explícita en que el marco aplica límites a claves, firmas, grupos y conjuntos a la vez, y en que el nivel cero permite todo lo que comprueba la función de retorno. Ese es el alcance de lo que cambió, y es la frase que hay que citar cuando alguien pregunta si el arreglo era estrecho.

El traspaso que sobrevive a una auditoría dice qué política rechazó qué entrada, qué se cambió y qué sigue aceptándose como resultado. «Funciona con SECLEVEL=0» es una observación sobre una conexión, no una evaluación de seguridad del despliegue.