Cómo funciona HTTPS por dentro: TLS 1.3, certificados y la cadena de confianza

Del texto plano a HTTPS: por qué ya no hay excusas

En 2015 Google anunció que HTTPS sería una señal de ranking. En 2018 Chrome empezó a marcar como "no seguro" cualquier sitio HTTP. Hoy no hay razón técnica ni económica para no cifrar: Let's Encrypt emite certificados gratuitos y automatizables. HTTPS no solo cifra: también autentica al servidor e impide manipulación en tránsito por proxies, ISPs y redes Wi-Fi hostiles.

El handshake TLS 1.3 en cuatro pasos

TLS 1.3 (RFC 8446, publicado en 2018) simplificó el handshake respecto a 1.2. Hoy la mayoría de conexiones lo usan:

1. ClientHello: el navegador envía la lista de cifrados que soporta, un nonce aleatorio y una clave efímera (ECDHE) para el intercambio. 2. ServerHello: el servidor elige un cipher suite, devuelve su clave efímera y su certificado. 3. Autenticación y derivación: el cliente verifica el certificado contra su almacén de CAs, deriva la clave compartida con Diffie-Hellman y envía Finished. 4. Application data: a partir de aquí todo el tráfico va cifrado con AEAD (AES-GCM o ChaCha20-Poly1305).

Con 0-RTT el cliente puede enviar datos en el primer paquete si ha hablado antes con el servidor, útil para APIs y CDNs.

Certificados X.509: qué contiene y qué firma quién

Un certificado es un documento firmado que dice "esta clave pública pertenece a este dominio". Contiene:

• Subject: el dominio (o wildcard, o lista SAN).
• Public key: normalmente ECDSA P-256 o RSA 2048.
• Issuer: la CA que firma.
• Validez: hoy máximo 398 días.
• Extensiones: SANs, key usage, OCSP endpoints.

La firma la produce la CA con su clave privada. Los navegadores traen una lista de CAs raíz preinstalada. Entre la raíz y tu certificado suele haber una o dos CAs intermedias. Si sirves solo tu certificado sin la cadena, muchos clientes fallarán la verificación.

Cadena de confianza y errores comunes

• NET::ERR_CERT_AUTHORITY_INVALID: falta la cadena intermedia o la CA no es reconocida.
• NET::ERR_CERT_DATE_INVALID: certificado caducado o reloj del sistema mal.
• NET::ERR_CERT_COMMON_NAME_INVALID: el hostname no coincide con Subject/SAN. Desde 2017 los navegadores ignoran Common Name y solo miran SANs.

Usa openssl s_client -connect dominio:443 -servername dominio para inspeccionar en producción.

HSTS, HPKP y las cabeceras que consolidan HTTPS

Un certificado válido no basta: alguien puede seguir intentando degradar la conexión con SSL-stripping en la primera visita HTTP. HSTS (Strict-Transport-Security) le dice al navegador "durante N segundos, para este dominio, solo HTTPS":

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Con preload puedes solicitar entrar en la lista precargada de Chrome/Firefox: quedas cubierto incluso en la primera visita, para siempre. Sé consciente: si algo va mal con tus certificados, quedas fuera hasta que expire.

HPKP (pinning) se retiró: era demasiado peligroso. Hoy se usa Certificate Transparency (CT logs) y Expect-CT para detectar emisiones fraudulentas.

Renovación automática con Let's Encrypt

Certbot, acme.sh o cert-manager (Kubernetes) automatizan todo el flujo ACME. Un cron cada 12 horas comprueba si algún certificado está a menos de 30 días de expirar y lo renueva. Emparejado con Nginx o Apache bien configurados, tienes HTTPS gratis, automático y con nota A+ en SSL Labs.

Checklist mínima para producción

• Certificado válido con cadena completa.
• TLS 1.2 y 1.3 activos; TLS 1.0/1.1 y SSL 3.0 deshabilitados.
• Cipher suites modernos (AEAD, forward secrecy).
• HSTS con max-age >= 6 meses, idealmente en preload list.
• Redirect 301 de HTTP a HTTPS en el propio servidor.
• Renovación automatizada y monitorizada (alertas 15 días antes de expiración).

HTTPS bien hecho no es solo un candado: es la base sobre la que se sostiene toda la seguridad de la web moderna.