TLS y PKI
El handshake TLS 1.3 paso a paso, qué valida el cliente de un certificado, cómo funciona la cadena de confianza y cómo gestionarlo en AWS con ACM.
Cada vez que ves el candado de HTTPS, acaba de ocurrir un pequeño milagro: tu navegador y un servidor que nunca se habían visto han acordado una clave secreta sobre un canal que cualquiera puede leer, y además tu navegador ha comprobado que el servidor es quien dice ser. Eso es TLSTLSProtocolo que cifra y autentica el tráfico de red; es la "S" de HTTPS. La versión vigente es TLS 1.3 (RFC 8446). apoyado en una PKIPKIEl sistema de CAs, certificados y cadenas de confianza que permite asociar una clave pública con una identidad verificada.. Entender el handshake te permite diagnosticar un certificado caducado, una cadena incompleta o un fallo de validación en lugar de reiniciar a ciegas.
El handshake TLS 1.3#
TLS combina las dos criptografías de las notas anteriores: un intercambio asimétrico acuerda una clave y el resto de la sesión va simétrica (AES-GCM). La versión vigente, TLS 1.3 (RFC 8446), simplificó el proceso a 1-RTT y eliminó lo inseguro: RSA estático para intercambio de claves, RC4, SHA-1, la compresión y la renegociación.
Paso 1 de 6ClientHello
El cliente abre con un ClientHello: versiones de TLS que soporta y su parte del intercambio de claves efímeras (key_share, ECDHE). Aún en claro.
El flujo de un handshake completo es:
- ClientHello: el cliente propone versiones de TLS, suites de cifrado y su mitad del intercambio de claves efímeras (
key_share, normalmente ECDHE). Va en claro. - ServerHello: el servidor elige los parámetros y manda su
key_share. Con ambas mitades, cada lado deriva el mismo secreto compartido. A partir de aquí, todos los mensajes del handshake van cifrados. - Certificado y Finished del servidor: el servidor envía su cadena de certificados, un
CertificateVerify(firma que prueba que posee la clave privada del certificado) y unFinished. - Validación y Finished del cliente: el cliente valida el certificado (lo vemos abajo), envía su
Finishedy ya puede fluir el tráfico de aplicación cifrado.
La clave efímera es lo que da forward secrecy: como las claves de ECDHE se generan nuevas en cada sesión y se descartan, comprometer la clave privada del servidor no permite descifrar sesiones pasadas que capturaron antes. En TLS 1.3 todos los modos con intercambio (EC)DHE lo garantizan.
Qué valida el cliente del certificado#
El certificado es el eslabón de confianza: contiene la clave pública del servidor y el nombre que afirma, firmado por una CA. El cliente no se fía porque sí; comprueba, como mínimo:
- Cadena hasta una CA raíz de confianza: el certificado del servidor lo firma una CA intermedia, que a su vez sube hasta una CA raíz que está en el almacén de confianza del sistema o del navegador. Cada firma de la cadena debe validar.
- Nombre: el dominio que visitas debe coincidir con el SAN (Subject Alternative Name) del certificado. El viejo Common Name ya no vale para esto.
- Vigencia: la fecha actual debe estar dentro del periodo
notBefore–notAfter. Un certificado caducado se rechaza. - Revocación: que la CA no lo haya revocado (vía CRL u OCSP).
Si algo falla, un cliente correcto aborta la conexión antes de enviar datos sensibles; por eso en el explainer el certificado no confiable corta el handshake. Una CA es, al final, un tercero en el que decidimos confiar para que avale identidades: ese es el corazón de la PKIPKIEl sistema de CAs, certificados y cadenas de confianza que permite asociar una clave pública con una identidad verificada..
TLS y PKI en AWS#
En la nube rara vez gestionas claves de certificado a mano. En Citas:
AWS Certificate Manager (ACM) emite certificados TLS públicos sin coste adicional, los renueva automáticamente (si usas validación DNS) y los integra con ALB, CloudFront y API Gateway. La clave privada la gestiona AWS: los certificados públicos estándar de ACM no se pueden exportar (la clave privada no es accesible), lo que reduce el riesgo de fuga.
resource "aws_acm_certificate" "citas" { domain_name = "citas.app" subject_alternative_names = ["www.citas.app"] validation_method = "DNS"}# Asócialo al listener HTTPS del ALB o a CloudFront;# ACM renueva solo mientras el certificado esté en uso.Para certificados internos (mTLS entre servicios, dispositivos, un dominio privado que no es público), AWS Private CA actúa como tu propia CA: emite certificados que solo son de confianza dentro de tu organización, porque tú distribuyes su CA raíz a tus clientes. Útil para zero trust de servicio a servicio sin exponer nada a Internet.
Para depurar desde la terminal, openssl es tu navaja suiza:
# Ver el handshake y la cadena que sirve un endpointopenssl s_client -connect citas.app:443 -servername citas.app
# Parsear un certificado: emisor, SAN, fechas de validezopenssl x509 -in cert.pem -text -nooutMira el issuer, el bloque X509v3 Subject Alternative Name y las fechas Not Before / Not After.
Tu turno
Inspecciona un certificado real
Elige un dominio que uses (el tuyo, o uno de tu laboratorio autorizado) y ejecútalo:
openssl s_client -connect TU-DOMINIO:443 -servername TU-DOMINIO </dev/null \ | openssl x509 -noout -issuer -subject -dates -ext subjectAltName- ¿Quién es la CA emisora y qué CA raíz cierra la cadena?
- ¿Qué nombres cubre el SAN? ¿Coincide con cómo accedes al servicio?
- ¿Cuánto le queda de vigencia? ¿Quién o qué lo renovará, y qué pasa si falla esa automatización?
Compara lo que ves con cómo esperabas que estuviera configurado: ahí suelen aparecer las sorpresas.
Reto
¿Por qué en TLS 1.3 el intercambio de claves es efímero (ECDHE) y no se cifra la clave de sesión con la clave pública RSA del servidor, como se hacía antes?
▸Mostrar solución
Por forward secrecy. Con el viejo RSA estático, la clave de sesión se cifraba con la clave pública del servidor; quien grabara el tráfico y más tarde robara la clave privada podía descifrar todas las sesiones pasadas. Con ECDHE efímero, las claves del intercambio se generan y descartan por sesión, así que una clave privada comprometida no abre el tráfico capturado antes. Por eso TLS 1.3 eliminó el intercambio RSA estático.
En resumen#
- TLS 1.3 acuerda una clave con un intercambio asimétrico efímero (ECDHE) y luego cifra todo con AES-GCM; el handshake es 1-RTT y todo lo posterior al ServerHello va cifrado.
- Las claves efímeras dan forward secrecy: robar la clave del servidor no descifra sesiones pasadas.
- El cliente valida el certificado: cadena hasta una CA raíz de confianza, nombre (SAN), vigencia y revocación. Si falla, aborta.
- La PKI es el sistema de CAs, cadenas y certificados que vincula una clave pública con una identidad.
- En AWS: ACM para certificados públicos autogestionados, Private CA para los internos, y openssl para inspeccionar.