Handshakes TLS fallan: resolver de forma fiable cadenas de certificados, SNI y renovación automática con ACME

TLS suele ser „invisible“ en el funcionamiento, hasta que llega el momento en que los handshakes TLS fallan y de repente el software empresarial, portales, APIs o integraciones no pueden establecer conexiones. Los síntomas suelen parecerse („Handshake failure“, „unknown ca“, „certificate verify failed“), pero las causas no: una cadena de certificados incompleta, un problema de SNI (Server Name Indication, es decir la selección del certificado adecuado según el nombre del host), un certificado caducado o renovado incorrectamente mediante ACME (Automated Certificate Management Environment, p. ej. Let’s Encrypt) o un proxy que reemplaza un certificado „en tránsito“.

Esta entrada está concebida como Runbook para administradores, ingenieros de sistemas, operadores y proveedores de servicios TI técnicos: con un orden claro de comprobación, checks concretos, trampas típicas, estrategias de implementación y de retroceso. El objetivo no es solo „volver a verde“, sino un estado estable y verificable —incluida la automatización y el monitorizado— para que el problema no reaparezca en cuatro semanas.

Qué ocurre realmente en el handshake TLS (y dónde suele romperse)

Un handshake TLS es la negociación de cifrado e identidad entre cliente y servidor. Simplificando ocurre lo siguiente: el cliente se conecta, indica (habitual en HTTPS) mediante SNI el nombre de host deseado, el servidor entrega un certificado (y, idealmente, los certificados intermedios), ambos negocian versión de protocolo y conjunto de cifrado, y el cliente verifica la cadena de confianza (Chain of Trust) hasta una Root-CA en el almacén de confianza.

Puntos de fallo en la práctica:

• Cadena de certificados incompleta: el servidor entrega solo el certificado leaf, falta el intermedio. Algunos clientes no pueden „recargarlo“ (según plataforma/política/offline).
• SNI no se aplica: el servidor entrega un certificado por defecto que no coincide con el host (CN/SAN mismatch). Frecuente con varios vHosts en una IP o con balanceadores de carga.
• Renovación/despliegue ACME defectuosos: el certificado se renovó, pero el servicio sigue usando el archivo antiguo / el binding antiguo / el keystore antiguo.
• Política de protocolo/cifrado incompatible: clientes legacy no soportan TLS 1.3, o el servidor bloquea TLS 1.2; ALPN (Application-Layer Protocol Negotiation) negocia HTTP/2 incorrectamente.
• mTLS (Mutual TLS) / certificados de cliente: el servidor espera un certificado de cliente; el cliente no presenta ninguno o presenta una CA incorrecta.
• Hora/CRL/OCSP: hora del sistema incorrecta, OCSP/CRL no alcanzables o configuraciones „Must-Staple“.

Evaluación inicial: determine la clase de síntoma antes de „tocar“ el certificado

Antes de cambiar certificados: clasifique el error. Esto ahorra tiempo y evita efectos secundarios, por ejemplo si un proxy causa el problema y usted modifica el backend.

Chequeo 1: ¿Afecta a todos los clientes o solo a algunos?

• Todos los clientes afectados: más bien certificado caducado, certificado incorrecto desplegado, SNI/certificado por defecto, endpoint equivocado (DNS/balanceador de carga).
• Sólo ciertas plataformas: frecuentemente problemas de cadena (intermedio), almacén de confianza, políticas Java antiguas o Windows, interoperabilidad TLS 1.3/1.2.
• Sólo clientes internos: proxy/inspection (TLS-Interception), distribución de CA interna, DNS dividido (Split-DNS).

Chequeo 2: ¿Dónde termina realmente TLS? (Encontrar el punto de terminación)

En entornos modernos, TLS a menudo no termina en el servidor de aplicaciones propiamente dicho, sino en el Reverse Proxy (Nginx/Apache), en el Load Balancer, en una WAF o en un API-Gateway. „Terminación de TLS“ significa: allí se descifra la conexión TLS y detrás continúa HTTP o TLS de nuevo (re-encriptación).

Consecuencia para la localización de fallos: debe probar el punto de terminación, no «el servidor». Si un Load Balancer termina la conexión, el certificado en el backend es irrelevante para el cliente externo.

Pruebas con OpenSSL y aseguramiento sistemático de evidencias

La afirmación más rápida y fiable suele obtenerse con openssl s_client. Importante: pruebe siempre con el nombre de host esperado (SNI), de lo contrario puede ver el certificado por defecto.

Comprobar SNI y la cadena de certificados en un solo paso

# SNI explizit setzen, Zertifikatskette anzeigen, OCSP-Informationen anfordern
openssl s_client 
  -connect example.com:443 
  -servername example.com 
  -showcerts 
  -status 
  </dev/null

En la salida debe fijarse en:

• subject / SAN: ¿coincide el nombre de host con los Subject Alternative Names (SAN)? El CN por sí solo ya no es suficiente para clientes modernos.
• issuer: ¿quién lo ha firmado? ¿CA/intermedio esperado?
• Verify return code: «0 (ok)» es bueno; códigos como «unable to get local issuer certificate» indican problemas con la cadena.
• Certificate chain: ¿se incluyen el certificado leaf y los intermedios? La raíz típicamente no debe enviarse.
• OCSP response: si se utiliza OCSP stapling debería aparecer una respuesta; en caso de errores suele verse timeouts/«no response».

Probar ALPN y la versión del protocolo (TLS 1.2 vs TLS 1.3)

# TLS 1.2 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# TLS 1.3 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

# ALPN-Angebot simulieren (z. B. HTTP/2 und HTTP/1.1)
openssl s_client -connect example.com:443 -servername example.com -alpn "h2,http/1.1" </dev/null

Por qué ayuda: algunos errores aparecen únicamente en determinados caminos de negociación, p. ej. cuando un proxy anuncia HTTP/2 (h2) pero lo mapea internamente de forma incorrecta, o cuando appliances antiguas no soportan correctamente TLS 1.3.

Causa frecuente 1: cadena de certificados incompleta (falta el intermedio)

Una cadena de certificados consta de un certificado Leaf (para su host), uno o varios certificados intermedios y una Root-CA que está en el almacén de confianza del cliente. Si el servidor no envía los certificados intermedios, algunos clientes no pueden completar la cadena, especialmente en entornos RESTrictivos sin acceso a AIA-URLs o con bloqueos por proxy.

Síntomas típicos

• El navegador A funciona, el navegador B o un cliente Java-/Windows falla.
• Mensajes de error: „unable to get local issuer certificate“, „unknown ca“, „self signed certificate in certificate chain“ (engañoso, frecuentemente un problema de cadena).
• Sólo ciertos middleboxes/clients MTLS afectados.

Cómo comprobar la cadena correctamente

Además de s_client conviene una segunda comprobación: extraiga los certificados y verifique si la cadena llega hasta una Root conocida.

# Zertifikate aus der s_client-Ausgabe in Dateien schreiben (manuell oder via Skript)
# Danach: Prüfen, ob Leaf gegen eine angegebene Chain verifizierbar ist
openssl verify -CAfile root-and-intermediate.pem leaf.pem

En la práctica la solución suele ser trivial pero decisiva: en el extremo TLS debe configurarse una Fullchain (Leaf + Intermediate), no sólo el certificado Leaf. En clientes ACME el archivo suele llamarse fullchain.pem (no cert.pem).

Errores comunes en operación

• Archivo incorrecto enlazado: Nginx/Apache apunta a cert.pem en lugar de fullchain.pem.
• Balanceador de carga „se traga“ el intermedio: según el producto la cadena debe importarse por separado o no se conserva correctamente al subirla.
• Formatos de keystore: Java (JKS/PKCS12) y Windows (almacén de certificados) suelen esperar la importación incluyendo la cadena; de lo contrario el Leaf queda „孤“.

Causa frecuente 2: configuración errónea de SNI y certificados por defecto

SNI (Server Name Indication) es una extensión de TLS mediante la cual el cliente indica el nombre del host ya en el establecimiento de la conexión. El servidor puede entonces seleccionar el certificado apropiado cuando varias dominios comparten la misma combinación IP/puerto.

Síntomas típicos

• Acceso por IP no funciona o devuelve un certificado incorrecto (esperable), pero el acceso por DNS también devuelve un certificado „incorrecto“.
• Un host bajo la misma IP funciona, otro no.
• Sólo clientes antiguos fallan (sin soporte SNI), p. ej. sistemas embebidos muy antiguos.

Verificar si realmente se entrega el certificado correcto

# Ohne SNI testen: Server wird Default-Zertifikat liefern
openssl s_client -connect example.com:443 -showcerts </dev/null

# Mit SNI testen: korrektes vHost-Zertifikat erwartet
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Si al conectar «sin SNI» aparece otro certificado, eso es normal. Si «con SNI» aun así aparece el certificado equivocado, la causa está en el punto de terminación: mapeo de vHost, asignación del listener, binding incorrecto o un dispositivo en la cadena que ya ha terminado el TLS-Handshake.

Riesgo: clientes heredados sin SNI

Si aún tiene clientes sin SNI en el campo, necesita una estrategia: IP/puerto dedicados para ese dominio, o un endpoint legado separado. En entornos B2B esto aparece, por ejemplo, en appliances antiguas, gateways de impresión/escaneo o gateways embebidos en producción.

Causa común 3: renovación automática con ACME – el certificado se ha renovado, pero no está activo

ACME automatiza la solicitud y la renovación. El riesgo operativo real a menudo no está en la renovación, sino en el despliegue: el certificado se ha renovado en disco, pero el servicio sigue usando el certificado antiguo porque falta un Reload/RESTart o porque está ligado un path incorrecto.

Comprender la validación ACME: HTTP-01, DNS-01, TLS-ALPN-01

• HTTP-01: El servidor ACME recupera un archivo token por HTTP (puerto 80). Falla por políticas de redirección, reglas WAF o ausencia de apertura de puertos entrantes.
• DNS-01: Token como registro DNS-TXT. Bueno para certificados wildcard y cuando el puerto 80 no es posible, pero depende de la automatización/propagación DNS.
• TLS-ALPN-01: Validación a través del puerto 443 y ALPN. Práctico cuando el puerto 80 no está abierto, pero puede colisionar con ciertos proxies o terminadores TLS.

Comprobar si el certificado nuevo está realmente activo

Compare la fecha NotAfter (expiración) y, idealmente, también el fingerprint del certificado en vivo con el artefacto esperado.

# Live-Zertifikat holen und Ablaufdatum anzeigen
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates -subject -issuer -fingerprint -sha256

Si el certificado en vivo es antiguo, aunque los archivos ACME sean nuevos, es un problema de despliegue/Reload.

Problemas comunes con ACME en la práctica

• Falta de Reload: El servicio lee los certificados solo al arrancar. Solución: Reload programado tras la renovación exitosa.
• Múltiples instancias: El certificado se renueva en el nodo A, pero el tráfico pasa por el nodo B. Solución: almacenamiento central, gestión de configuración o distribuirlo mediante hooks.
• Contenedores/Immutable Deployments: El certificado está en el host; el contenedor no lo ve (falta el volume) o el Ingress-Controller lo gestiona por separado.
• Permisos de archivo/SELinux/AppArmor: La renovación escribe un archivo nuevo, el servicio no puede leerlo después.
• Clock Skew: Desviaciones de tiempo provocan «not yet valid» o comprobaciones OCSP frágiles.

Automatización ACME robusta: Hooks, Reload und Idempotenz

Independientemente del cliente ACME (certbot, acme.sh, win-acme etc.) se ha demostrado un patrón: tras una renovación exitosa, un deploy-hook que (1) despliega archivos/bundles de forma consistente, (2) ajusta permisos, (3) realiza un reload controlado y (4) inicia una prueba de humo.

# Beispiel: certbot mit deploy-hook (Linux)
# Der Hook läuft nur, wenn wirklich erneuert wurde.
certbot renew 
  --deploy-hook "/usr/local/sbin/tls-deploy-and-reload.sh"

El hook en sí debería ser „idempotente“ (ejecutable varias veces sin efectos secundarios) y devolver códigos de salida claros, para que el monitoring/los jobs puedan alertar de forma fiable.

mTLS und Client-Zertifikate: Wenn der Server den Client ablehnt

Con mTLS (mutual TLS) no solo el servidor se autentica ante el cliente, sino que también el cliente se autentica ante el servidor mediante un certificado de cliente. Esto es habitual en integraciones internas, conexiones B2B con socios o en endpoints de administración.

Typische Symptome

• El handshake falla con „handshake failure“ o „bad certificate“.
• Los logs del servidor muestran: „no required SSL certificate was sent“ o „unknown ca“ (en relación con la Client-CA).

Prüfpfad

• ¿Exige el endpoint realmente mTLS (Policy/Location/Listener)?
• ¿Está configurada en el servidor como de confianza la CA que emite los certificados de cliente?
• ¿Coinciden el EKU/Key Usage (Extended Key Usage: „Client Authentication“) en el certificado de cliente?
• ¿Se mapea correctamente SNI/Host a la política mTLS (no por error al listener „public“)?

Protokoll- und Cipher-Policy: Wenn Security-Härtung unerwartet Clients aussperrt

Muchas fallas TLS surgen tras medidas de endurecimiento: desactivación de TLS 1.0/1.1 (generalmente acertada), listas de cifrados demasiado RESTrictivas, imposición de TLS 1.3 o selección estricta de curvas. Esto no es un argumento en contra del endurecimiento, sino a favor de una migración controlada con puntos de medición.

Praxisregel: Erst messen, dann schalten

• ¿Qué clientes están conectados (Browser, Java, .NET, Appliances, Partner)?
• ¿Qué protocolos se están utilizando realmente (TLS 1.2/1.3)?
• ¿Existen requisitos de compliance que ya exijan TLS 1.2+?

En situaciones de resolución de problemas ayuda una atenuación temporal para acotar la causa. Importante: solo con ventana de cambio, documentado y con una reversión clara.

Prüfcheckliste: In 20 Minuten zur wahrscheinlichsten Ursache

Si está bajo presión de tiempo, use este orden. Minimiza el trabajo de prueba y error y proporciona pruebas útiles rápidamente.

1. Determinar el punto de terminación: DNS → Load Balancer → WAF → Reverse Proxy → App. Probar en ese punto.
2. Obtener el certificado en vivo (con SNI): SAN, Issuer, NotAfter, Fingerprint.
3. Comprobar la cadena de certificados: ¿se entrega la fullchain? Revisar el Verify-Code.
4. Prueba A/B de SNI: comparar con y sin -servername.
5. Comprobar versiones TLS: forzar tls1_2 / tls1_3, probar ALPN.
6. Aclarar mTLS: ¿espera el servidor un certificado de cliente?
7. Comprobar el estado ACME: logs de renovación, última renovación exitosa, ¿se ejecutó el hook/reload?

Umsetzung: Saubere Betriebsmaßnahmen, damit es nicht wieder passiert

Los problemas TLS rara vez son „puntuales“. Sin medidas operativas vuelven a ocurrir: con el siguiente cambio de intermediarios, el siguiente rollover de certificados, la próxima actualización del Load-Balancer o cuando se reconstruye un nodo del cluster.

1) Monitoring auf Ablauf und auf echten Handshake

No basta con vigilar solo la fecha de caducidad. Necesita al menos dos señales:

• Caducidad del certificado: NotAfter dentro de un umbral (p. ej. 14/7/3 días).
• Handshake real desde el exterior: SNI correcto, Chain válida, versión TLS ok. Esto cubre problemas de SNI/Chain/despliegue.

2) Plan de cambios y Rollback para certificados

Un rollback pragmático significa: poder volver en pocos minutos al certificado/binding anterior. Para ello necesita:

• Almacenamiento versionado de los artefactos del certificado (como mínimo la versión anterior), con control de acceso.
• Rutas/Bindings documentadas por servicio (p. ej. Nginx-Config, IIS-Binding, Load-Balancer-Listener).
• Un proceso definido de reload/RESTart y una prueba de humo (Handshake + estado HTTP +, si procede, llamada a la API).

3) Operar ACME de forma adecuada en entornos Multi-Node

En entornos HA, la distribución es determinante. Patrones robustos típicos:

• Gestión centralizada de certificados en el punto de terminación: ACME se ejecuta directamente en el Load Balancer/Reverse Proxy, no «en algún lugar» del backend.
• Pull en lugar de Push: Los nodos obtienen el certificado periódicamente desde un almacén seguro (Secrets-Management) y realizan un reload controlado.
• Hooks con Health-Gate: No se ‚commit‘ el despliegue hasta que el nuevo Handshake en el listener objetivo sea exitoso.

Estrategia de respaldo en incidentes: estabilizar, luego mejorar

Cuando fallan las interfaces productivas, importa el orden:

• Estabilizar: entregar un certificado correcto con cadena válida; si es necesario, volver temporalmente a una policy conocida y funcional (permitir TLS 1.2, una Cipher-Baseline limpia).
• Verificar: probar desde varias redes/clients (interno/externo), documentar pruebas de SNI, registrar Fingerprints.
• Corregir la causa: ACME-Deployment, fullchain incorrecta, SNI-Mapping erróneo, distribución en el cluster.
• Endurecer: volver a endurecer la Security-Policy, pero con puntos de medición y rollback.

Es importante no basar el «fix» únicamente en el síntoma. Por ejemplo, si la renovación en el Node A funciona, pero el Node B sigue sirviendo el certificado antiguo, no es un problema de certificados, sino un problema de distribución y operación.

Conclusión: TLS-Handshakes fallan — pero las causas son manejables con un runbook claro

Cuando los TLS-Handshakes fallan, el mayor riesgo no es la criptografía, sino la complejidad operacional: varios puntos de terminación, SNI-Mapping, cadenas de certificados, automatización y mecánica de reload. Con una secuencia de comprobación fija (punto de terminación → Live-Zertifikat con SNI → Chain → protocolos/ALPN → ACME-Deployment) se llega rápidamente a la causa. Será sostenible sólo con medidas operativas: Handshake-Monitoring, artefactos de certificado versionados, hooks controlados y una vía de rollback ensayada.

Para este tema también son importantes la mala configuración de SNI y la renovación automática de ACME. El artículo sitúa estos aspectos de forma comprensible y muestra qué importa en el día a día.