TLS (Transport Layer Security) es el protocolo que da soporte a HTTPS y a otras comunicaciones cifradas. Su objetivo es evitar escucha (eavesdropping), manipulación (tampering) y suplantación del canal durante la comunicación cliente-servidor.

Lo importante para tomar decisiones correctas:

  • TLS sí protege el canal (cifrado e integridad) y autentica al servidor mediante certificado.
  • TLS no sustituye controles de aplicación (autorización, CSRF, XSS, etc.).
  • TLS depende de protocolos, cifrados, certificado, cadena y validación; una debilidad en cualquiera puede causar errores o degradar seguridad.

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

1) Diagnóstico rápido: qué medir antes de tocar configuración

Antes de “endurecer”, recomendamos capturar evidencia reproducible:

  1. Prueba externa (scanner): SSL Labs / Mozilla Observatory (como referencia operativa). MDN recomienda estas herramientas para evaluar configuración TLS/HTTP.
  2. Prueba desde terminal: openssl s_client para ver handshake, cadena, SNI y (si aplica) stapling. La documentación oficial de OpenSSL describe s_client como herramienta para inspección y verificación.
  3. Inventario de compatibilidad: qué clientes debemos soportar (navegadores antiguos, integraciones IoT, SDKs embebidos). Esto define si podemos ir a “modern” o “intermediate”.

Para configurar de forma segura y compatible, Mozilla mantiene un generador de configuración TLS por software (Nginx/Apache/HAProxy, etc.) con perfiles “modern/intermediate”.

2) “No se pudo validar TLS”: causas típicas (SNI, cadena, handshake) y diagnóstico

Cuando un cliente no puede validar TLS, el fallo suele caer en tres grupos.

2.1 SNI incorrecto o ausente (certificado no corresponde al hostname)

En servidores con múltiples sitios por IP (virtual hosts), el cliente debe indicar el hostname durante el handshake mediante la extensión server_name (SNI). Esto está definido en las extensiones TLS.

Síntomas típicos

  • El servidor entrega el certificado “por defecto” (de otro dominio).
  • El navegador marca “certificado no válido / nombre no coincide”.

Cómo diagnosticar

  • Comparar handshake con y sin SNI:
    • openssl s_client -connect dominio:443 -servername dominio
    • vs. openssl s_client -connect ip:443
      OpenSSL documenta el uso de s_client para inspeccionar cadena y verificación.

Causas probables (y cómo verificarlas)

  • vhost TLS mal configurado: confirmar server_name/ServerName y el bloque que sirve 443.
  • CDN/Proxy: confirmar que el edge o el origin están entregando el cert correcto para ese hostname.

2.2 Cadena incompleta o confianza rota (intermedias)

Este caso es tan común que aparece incluso en diagnósticos habituales de OpenSSL: errores de verificación suelen indicar que falta un certificado emisor/intermedio en la cadena presentada.

Síntomas

  • “chain verify failed”, “unable to get issuer certificate”, etc.

Diagnóstico

  • openssl s_client -showcerts ... y revisar si el servidor entrega intermedias.
  • Validar en SSL Labs qué parte de la cadena falta.

Nota operativa: no basta con “tener el root”; normalmente el servidor debe servir el bundle con la(s) intermedia(s) correctas.

2.3 Handshake fallido por incompatibilidad de protocolos/cifrados

Si el servidor solo permite TLS 1.3 y el cliente es antiguo, o si el servidor ofrece cifrados incompatibles, el handshake puede fallar.

Diagnóstico

  • Probar versión/protocolos y ver qué negocia el cliente.
  • Correlacionar con la configuración de protocolos (TLS 1.2/1.3) y lista de cifrados.

OWASP advierte que configuraciones débiles o incompatibles pueden forzar negociaciones inseguras o fallos, y recomienda soportar protocolos/cifrados fuertes.

3) Certificado TLS caducado: impacto y pasos de corrección sin downtime

3.1 Impacto real

  • El navegador normalmente bloquea la navegación o muestra alertas severas.
  • Si tenemos HSTS (estricto), el usuario puede quedar sin posibilidad de bypass en algunos escenarios (alto impacto operativo).
  • APIs/SDKs suelen fallar automáticamente, generando incidentes en cadena.

3.2 Corrección sin downtime (enfoque operativo)

El objetivo es rotar certificado y recargar sin interrumpir el servicio.

Plan recomendado

  1. Emitir/obtener un certificado nuevo (idealmente automatizado).
  2. Verificar cadena completa y SANs (dominios) incluidos.
  3. Desplegar el nuevo certificado en el punto de terminación TLS:
    • si hay CDN/WAF, primero edge o siguiendo su modelo,
    • si hay LB, desplegar en LB y/o en origin según arquitectura.
  4. Hacer reload (no restart) del servicio cuando sea posible.
  5. Validar externamente (SSL Labs / openssl s_client) y monitorizar errores.

Para evitar reconfigurar “a ciegas”, recomendamos basarnos en configuraciones de referencia (por ejemplo, Mozilla SSL Configuration Generator) y validar después.

4) Certificado TLS por caducar: cómo planificar renovación y evitar alertas

Aquí la diferencia entre “incidencia” y “operación madura” es la planificación.

Buenas prácticas

  • Renovar con margen (por ejemplo, 15–30 días antes), evitando “ventanas críticas”.
  • Mantener automatización (ACME) y alertas:
    • alerta a 30/15/7/1 días,
    • verificación de que el nuevo certificado está sirviéndose realmente.
  • Validar cadena y OCSP (si aplica) tras renovación.

Riesgo típico

  • Renovamos en disco, pero el proceso TLS no recarga (sigue sirviendo el cert viejo).

Verificación

  • openssl s_client y revisar notAfter.
  • SSL Labs para confirmar fecha y cadena.

5) Sin TLS moderno (1.2/1.3): riesgos y cómo actualizar compatibilidad

TLS 1.3 es la versión actual del protocolo; el RFC 8446 describe mejoras de seguridad y rendimiento y obsoleta versiones previas en varios aspectos.

Además, las recomendaciones modernas (BCP) se apoyan en TLS 1.2/1.3 porque ciertos cifrados recomendados solo existen en TLS 1.2+.

Riesgos de no soportar TLS 1.2/1.3

  • Incompatibilidades con clientes modernos (algunos entornos ya no aceptan TLS antiguo).
  • Exposición a suites y mecanismos obsoletos.

Plan de actualización (sin romper)

  1. Habilitar TLS 1.2 + TLS 1.3.
  2. Mantener un conjunto de cifrados “intermediate” si necesitamos compatibilidad.
  3. Medir tráfico por versión (si tenemos telemetry) y retirar progresivamente lo viejo.

Mozilla ofrece perfiles listos para Nginx/Apache según compatibilidad deseada.

6) TLS legacy habilitado: por qué TLS 1.0/1.1 es mala idea y cómo desactivarlo

TLS 1.0 y 1.1 están formalmente deprecados en un documento de mejores prácticas (BCP 195).
Además, grandes plataformas han avanzado en su retirada en sistemas y librerías; Microsoft documenta la deprecación y su impacto en Windows y aplicaciones.

Por qué es mala idea (operativo y seguridad)

  • Mantener múltiples versiones aumenta superficie y riesgo de configuración errónea.
  • Algoritmos y suites asociadas no cumplen recomendaciones actuales.

Cómo desactivarlo (enfoque)

  • Ajustar ssl_protocols / SSLProtocol para permitir solo TLS 1.2 y 1.3.
  • Validar que no dependemos de clientes legacy (inventario).

OWASP incluye como recomendación no usar protocolos legacy y enfocarse en configuraciones fuertes.

7) Cifrados TLS débiles permitidos: qué son y cómo endurecer la configuración

Los “cifrados débiles” suelen implicar:

  • suites antiguas,
  • modos inseguros/obsoletos,
  • ausencia de AEAD moderno,
  • o intercambio de claves sin forward secrecy.

OWASP recomienda habilitar solo cifrados fuertes (idealmente AEAD como GCM cuando sea posible) y evitar configuraciones que permitan degradación a cifrados débiles.

Enfoque de endurecimiento

  1. Elegir un perfil (modern/intermediate) según compatibilidad.
  2. Definir lista explícita de cifrados permitidos.
  3. Deshabilitar suites heredadas.
  4. Verificar con SSL Labs y con pruebas reales de clientes críticos.

Para no inventar listas, recomendamos partir de configuraciones de referencia mantenidas (Mozilla SSL Configuration Generator).

8) Sin Perfect Forward Secrecy: qué es PFS y cómo forzarlo

Perfect Forward Secrecy (PFS) implica que, aunque un atacante obtenga la clave privada del servidor en el futuro, no podrá descifrar sesiones pasadas capturadas (porque cada sesión negocia claves efímeras).

En la práctica, se logra priorizando suites con ECDHE (o DHE) frente a intercambios estáticos.

OWASP relaciona el endurecimiento de cifrados y el uso de suites fuertes como parte del diseño seguro de TLS (y, operativamente, PFS forma parte de lo que buscamos al seleccionar suites modernas).

Cómo forzarlo

  • En TLS 1.2, priorizar ECDHE-* y excluir suites sin intercambio efímero.
  • En TLS 1.3, el diseño ya va en línea con negociaciones modernas (no se elige “RSA key exchange” como en el pasado).

9) Fallo al verificar la cadena del certificado (chain trust): causas y solución

Este punto merece sección propia porque es una de las causas más frecuentes de incidentes tras renovaciones.

9.1 Causas típicas

  • Falta de intermediate CA en el bundle entregado por el servidor.
  • Bundle desordenado o incorrecto.
  • Certificado del servidor no corresponde con la clave privada desplegada (mismatch).
  • Proxy/CDN sirviendo un cert distinto al esperado.

9.2 Diagnóstico

  • openssl s_client -showcerts ... y extraer la cadena.
  • Revisar errores de verificación; OpenSSL permite ver problemas de cadena durante la conexión.

9.3 Solución

  • Servir full chain correcto (certificado leaf + intermedias).
  • Verificar contra stores comunes (Linux ca-certificates, Android, etc.).
  • Revalidar externamente.

10) OCSP Stapling ausente: cuándo importa y cómo habilitarlo

10.1 Qué es y por qué se usa

OCSP stapling permite que el servidor incluya (staple) una respuesta OCSP firmada por la CA durante el handshake, evitando que el navegador tenga que consultar a la CA directamente. Esto mejora rendimiento y privacidad (menos consultas de revocación por parte del cliente).

La extensión status_request (base de OCSP stapling) está descrita en las extensiones TLS.

10.2 Cuándo importa más

  • Sitios con alto tráfico: reduce latencia agregada.
  • Entornos donde la privacidad de consultas a la CA es relevante.
  • Cuando buscamos “calidad TLS” elevada en auditorías externas.

10.3 Cómo habilitarlo (enfoque)

Depende del servidor, pero el patrón común incluye:

  • activar stapling,
  • activar verificación de stapling,
  • configurar cadena de confianza para verificar OCSP y un resolver DNS.

Guías de CAs como DigiCert describen el funcionamiento y pasos generales.
Además, problemas típicos al activar verificación de stapling suelen requerir configurar certificados de confianza adicionales (chain) para que el servidor verifique la respuesta OCSP.

11) Checklist de cierre

Validación

  • Handshake correcto con SNI y sin SNI (si aplica); el certificado coincide con el hostname.
  • Cadena completa servida (leaf + intermedias) y verificación sin errores.
  • Certificado vigente (notBefore/notAfter) y monitorización de expiración activa.
  • TLS 1.2/1.3 habilitado; TLS 1.0/1.1 deshabilitado conforme a BCP.
  • Cifrados fuertes (perfil “intermediate/modern”), sin suites débiles.
  • PFS garantizado (prioridad ECDHE en TLS 1.2).
  • OCSP stapling habilitado y verificado (si el entorno lo soporta).