TLS 1.3: qué cambia y cómo comprobarlo
Actualizado 2026-11-03 · 6 min de lectura
TLS 1.3 es la primera revisión de protocolo en una década que quita funciones en lugar de añadirlas. Eso es lo que lo hace más rápido y más difícil de configurar mal, y por eso un servidor que solo habla TLS 1.2 no puede alcanzar la nota máxima.
Qué cambió respecto a TLS 1.2
TLS 1.3 reduce el handshake de dos idas y vueltas a una, y a cero en la reanudación. Elimina el intercambio de claves RSA y Diffie-Hellman estático, así que la confidencialidad hacia delante pasa de opcional a obligatoria. Descarta por completo las suites en modo CBC, RC4, SHA-1 y la compresión, y cifra más parte del handshake —incluido el certificado— para que los intermediarios aprendan menos.
La consecuencia práctica es que casi todas las debilidades heredadas que antes exigían configuración cuidadosa ahora son imposibles. No puedes negociar por accidente una suite débil en TLS 1.3, porque el protocolo solo define suites AEAD con hashes modernos.
Por qué importa para tu nota
CertH exige TLS 1.3 para un A+ sin importar todo lo demás. Un sitio con certificado perfecto, cifrados fuertes y HSTS se queda en 95 y una A sin él. Esa sola línea es el motivo más frecuente por el que un sitio bien gestionado se estanca en A.
La otra razón para preocuparse es el propio handshake. En una conexión móvil de alta latencia, una ida y vuelta ahorrada son decenas o cientos de milisegundos en cada conexión nueva: un efecto directo y medible en la velocidad percibida.
Activarlo
En nginx, el soporte de TLS 1.3 depende de la versión de OpenSSL con la que se compiló el binario. Se requiere OpenSSL 1.1.1 o superior; compruébalo con nginx -V buscando la cadena built with OpenSSL antes de tocar nada.
En Apache, SSLProtocol basta siempre que httpd esté enlazado con un OpenSSL moderno. En Cloudflare, TLS 1.3 es un interruptor a nivel de zona en SSL/TLS → Edge Certificates y está activo por defecto en la mayoría de zonas desde 2021.
# nginx: does this binary even support TLS 1.3?
nginx -V 2>&1 | tr ' ' '\n' | grep -i openssl
# negotiate TLS 1.3 explicitly and print the protocol
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"Los detalles que nadie menciona
La reanudación 0-RTT es rápida pero reutilizable: un atacante que capture el primer vuelo puede reenviarlo. Nunca permitas 0-RTT en endpoints que cambian de estado en la primera petición, como cualquier cosa que escriba.
Algunos middleboxes corporativos todavía fallan con TLS 1.3. Mantener TLS 1.2 activo en paralelo es el compromiso estándar: conservas compatibilidad y sigues cumpliendo el requisito de A+, porque el evaluador busca que se ofrezca TLS 1.3, no que se desactive TLS 1.2.
Por último, un CDN o balanceador que termina el TLS oculta por completo el origen. Cambiar el origen sin cambiar el edge no cambia nada de lo que un escáner externo puede ver.
FAQ
¿Debo desactivar TLS 1.2 cuando TLS 1.3 está activo?
No. Mantener TLS 1.2 preserva la compatibilidad con clientes antiguos y middleboxes y no cuesta puntos. Desactivarlo solo elimina opciones de repliegue.
¿TLS 1.3 cambia los requisitos de mi certificado?
Hace inutilizables algunos algoritmos heredados. Los certificados con clave RSA siguen valiendo, pero la cadena debe usar algoritmos de firma que el protocolo permita; las firmas SHA-1, por ejemplo, no son utilizables en TLS 1.3.