SincroDev Logo SincroDev

Perfil de GitHub de Walter Rodriguez

TLS/HTTPS por dentro: handshake, certificados y cadena de confianza

Introducción

Sabemos que HTTPS cifra la comunicación, pero muchas veces se queda en eso. En producción, entender TLS marca la diferencia entre “funciona en mi máquina” y una plataforma confiable.

Este artículo recorre el flujo real: handshake, certificados, confianza y fallos típicos.

HTTP vs HTTPS: qué cambia (y qué no)

  • HTTP y HTTPS siguen usando el mismo modelo petición-respuesta.
  • Lo que cambia es el canal: con HTTPS, HTTP viaja dentro de un túnel TLS cifrado.
  • HTTPS protege datos en tránsito, pero no corrige problemas de lógica de negocio, XSS o permisos mal diseñados.

TLS handshake paso a paso (versión moderna)

Cuando cliente y servidor se conectan:

  1. ClientHello: el cliente propone versión TLS, cifrados soportados y envía SNI (dominio).
  2. ServerHello: el servidor elige parámetros y responde con su certificado.
  3. Verificación de certificado: el cliente valida dominio, fechas, emisor y cadena de confianza.
  4. Intercambio de claves: ambas partes derivan una clave de sesión efímera.
  5. Canal cifrado activo: ya puede circular HTTP de forma segura.

En TLS 1.3, este flujo es más corto y rápido que en versiones antiguas.

Certificados y cadena de confianza

Un certificado X.509 afirma: “este dominio corresponde a esta clave pública”.

Elementos clave:

  • CN/SAN: nombres de dominio válidos.
  • Issuer: autoridad certificadora (CA) que lo firma.
  • Validez: fecha not before y not after.
  • Cadena: certificado del sitio + intermedios + raíz confiable en el sistema.

Si falta un intermedio, muchos clientes fallarán aunque el certificado “parezca correcto”.

SNI y ALPN: dos detalles críticos

  • SNI permite que un mismo servidor entregue el certificado correcto según dominio.
  • ALPN negocia el protocolo de aplicación (por ejemplo HTTP/1.1 o HTTP/2).

Cuando SNI no llega bien (proxy mal configurado), aparecen errores de certificado inesperados.

Errores comunes en producción

  • Certificado expirado.
  • Dominio no incluido en SAN.
  • Cadena incompleta (faltan intermedios).
  • Hora del servidor o cliente desfasada.
  • TLS obsoleto o suites inseguras.

Síntomas típicos: NET::ERR_CERT_COMMON_NAME_INVALID, CERT_DATE_INVALID, SSL_ERROR_HANDSHAKE_FAILURE.

Checklist mínimo para un HTTPS sano

  • Forzar TLS moderno (1.2+; ideal 1.3 habilitado).
  • Renovación automática de certificados.
  • Redirección 301 de HTTP a HTTPS.
  • HSTS una vez validada la configuración.
  • Monitoreo de expiración y alertas.
  • Pruebas externas periódicas (por ejemplo SSL Labs).

Cierre

HTTPS no es solo “poner un candado”. Es una cadena de decisiones técnicas que deben estar bien afinadas. Si dominas handshake, certificados y validación, depuras incidencias más rápido y reduces riesgo real.

Lecturas relacionadas