Errores de verificación TLS en distintas herramientas: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain

Qué es

Varios clientes TLS describen con su propio vocabulario exactamente el mismo fallo de fondo: no han podido construir una cadena desde el certificado del servidor hasta uno en el que ya confían. El paquete crypto/x509 de Go informa x509: certificate signed by unknown authority (desde Go 1.20 con el prefijo tls: failed to verify certificate:). El módulo ssl de Python, que envuelve OpenSSL, lanza [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate, un error documentado en la propia referencia del módulo. curl informa curl: (60) SSL certificate problem: seguido de unable to get local issuer certificate o self-signed certificate in certificate chain, según el punto exacto en que se rompe la cadena, tal como describe la documentación de curl sobre problemas de certificados SSL; OpenSSL 1.1.1 lo escribe self signed. Node.js y openssl s_client informan de una cadena que contiene solo el certificado hoja, procedente de un emisor desconocido, como unable to verify the first certificate.

Por qué importa

El mensaje sugiere la causa raíz, pero no la identifica de forma fiable, y adivinar hace perder tiempo: un certificado intermedio ausente es un error de configuración del servidor; una raíz autofirmada al final de la cadena es o bien una CA privada legítima o, en casos poco frecuentes, una interceptación en curso; y ninguno de los dos casos se resuelve desactivando la verificación.

Cómo aplicarlo

• Diagnostica primero: openssl s_client -connect host:443 -servername host </dev/null, documentado en la página de manual de s_client de OpenSSL, muestra la cadena de certificados que envió el servidor (añade -showcerts para ver los bloques PEM completos) y una línea Verify return code: al final. Si la cadena termina en el certificado hoja sin ningún intermedio, el servidor no está enviando su paquete de certificados intermedios. Si los campos issuer y subject del último certificado son idénticos, la cadena termina en un certificado autofirmado: o bien es tu propia CA privada o interna, en la que el cliente aún no confía, o bien, si no esperabas ninguna raíz autofirmada, es una señal de que el tráfico podría estar siendo interceptado.
• Soluciones, de la menos a la más invasiva:
  1. Intermedio ausente con una CA que por lo demás es pública: corrige el paquete de certificados del propio servidor para que incluya la cadena completa; no es un problema del lado del cliente.
  2. CA privada o interna (habitual detrás de proxies corporativos y en algunos runners de CI): instala esa CA en el almacén de confianza que la herramienta que falla realmente lee, ya que el cacerts de Java, el paquete certifi de Python, el almacén propio de Node y el almacén del sistema de curl/OpenSSL son independientes entre sí.
  3. Si la cadena cambió de forma inesperada y se sospecha una interceptación, trátalo como un incidente de seguridad: verifica el certificado por un canal independiente antes de continuar, no desactivando la comprobación.
• No seguro: curl -k/--insecure, verify=False de Python, NODE_TLS_REJECT_UNAUTHORIZED=0 o git -c http.sslVerify=false. Cada una desactiva justo la comprobación que detectaría un ataque de intermediario (machine-in-the-middle) real, y ninguna debería convertirse en una solución permanente.

Trampas

• Arreglar el almacén de confianza de una herramienta (el del sistema operativo) mientras otra (una JVM, un venv de Python) mantiene su propio paquete independiente y sigue fallando.
• Tomar una interceptación temporal (un proxy corporativo que inspecciona TLS) como permiso para desactivar la verificación en todas partes, en lugar de confiar únicamente en la CA específica de ese proxy.