Propósito de certificado no admitido: por qué falla la CA intermedia

El propósito del certificado del servidor parece correcto, la clave coincide, las fechas están bien, y la conexión sigue fallando con unsupported certificate purpose. El detalle que lo resuelve suele estar en la misma línea que el error: un valor de profundidad y un subject que nombran un certificado más arriba en la cadena. Se ejecutan dos pruebas distintas, y solo una de ellas trata del certificado final. Compararlas explica por qué sustituir el certificado del servidor no cambia nada.

Qué certificado rechazó realmente el verificador

Una cadena no es un objeto repetido tres veces. El certificado final lleva el nombre y la clave del servidor, los intermedios lo enlazan con una raíz, y cada uno tiene su propio periodo de validez, restricciones y usos. Cuando el error nombra una profundidad, ese número identifica una posición en la cadena que construyó el verificador, y puede que no sea la posición que espera si el servidor envía una cadena inesperada.

Lea los campos del certificado en esa profundidad en lugar del certificado que asumió culpable. Pida las dos extensiones que restringen la emisión en vez de volcar todos los campos, porque la respuesta casi siempre está en una de ellas. La salida de las extensiones se puede compartir; las claves privadas nunca.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Si el certificado nombrado es un intermedio cuyo uso extendido de clave menciona algo ajeno a la autenticación de servidor TLS, el resto del fallo se sigue mecánicamente. La cadena no se puede usar para el propósito que solicitó OpenVPN.

El propósito del certificado final y la política de la cadena son dos pruebas

La prueba del certificado final plantea una pregunta estrecha: ¿este certificado de entidad final permite la autenticación de servidor para este nombre? La prueba de la cadena plantea una más amplia: ¿puede cada certificado de la ruta servir a ese propósito? Una autoridad de certificación autorizada a emitir solo certificados de cliente pasará sus propias comprobaciones de firma y aun así fallará la segunda prueba, porque la ruta que autoriza no incluye el propósito que necesita la aplicación. Las dos pruebas fallan con las mismas palabras y tienen reparaciones completamente distintas.

Por eso un certificado final recién emitido, correcto en todos los campos visibles, puede fallar de inmediato. También por eso la corrección suele pertenecer al perfil de la autoridad emisora y no a la configuración de la VPN.

Un EKU ausente no es un EKU restrictivo

La RFC 5280 hace opcional la extensión de uso extendido de clave y, cuando está presente, restrictiva. Un certificado de CA sin la extensión, por tanto, no ha dicho «no» a la autenticación de servidor, mientras que uno que solo enumera un propósito ajeno ha dicho algo muy concreto. Tratar esos dos estados como equivalentes produce el diagnóstico equivocado y, peor, la reparación equivocada. La distinción también explica por qué dos autoridades que parecen iguales en una consola se comportan de forma totalmente distinta en una cadena.

El comportamiento de las bibliotecas tampoco es uniforme aquí. documento de OpenSSL sobre las opciones de verificación describe su propio tratamiento de las comprobaciones de propósito en certificados de CA, y ese tratamiento es una política de implementación, no una regla que todas las pilas TLS sigan de manera idéntica. Describa lo que hace su verificador y luego confírmelo con la versión que ejecuta realmente.

Reproduzca el fallo sin conexión antes de reemitir

Una verificación sin conexión saca a la aplicación de la ecuación. Si la cadena falla igual con el mismo propósito, el problema es el certificado y ninguna configuración del servidor lo ocultará. Si la cadena pasa sin conexión mientras el servicio sigue negándose, la aplicación solicita otro propósito o usa una cadena distinta de la que probó.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain importa porque imprime la ruta que construyó la herramienta, que a menudo no es el orden de archivos que proporcionó. Esa salida es la forma más rápida de descubrir que se está extrayendo un segundo intermedio de un almacén de confianza, que el servidor envía una variante firmada de forma cruzada que no pretendía, o que la marca de propósito que copió de un tutorial pertenece a un rol distinto del que se sirve.

Corrija la política de emisión, no la llamada de verificación

La reparación duradera es un intermedio emitido bajo una política que permite los propósitos que debe servir, con la restricción escrita y revisada. Añadir todos los propósitos a todas las autoridades no es una política; elimina la restricción que daba sentido a la extensión y suele sobrevivir al incidente que la motivó. Una nota breve en el perfil que describa qué roles puede certificar la autoridad evita que la siguiente reemisión repita la misma discusión.

Desactivar la verificación es el otro atajo tentador, y convierte un problema de certificado en un problema de confianza. Mantenga la comprobación de propósito, corrija la cadena y vuelva a ejecutar la misma verificación sin conexión para confirmar que la ruta ya sirve al rol previsto antes de tocar el servicio de nuevo.