TLS 1.3: certificado y handshake, 6 ejercicios resueltos para TAI
Respuesta rápida: el certificado no es una contraseña ni una sesión cifrada: presenta una clave pública e identidad verificable. En TLS 1.3 las claves de handshake se derivan antes del Certificate del servidor; la firma CertificateVerify demuestra posesión de la clave privada asociada.
Ordena las piezas del protocolo
El RFC 8446 define TLS 1.3. En una conexión completa, el cliente anuncia capacidades en ClientHello; el servidor responde con ServerHello, y ambos derivan secretos de handshake. Después el servidor envía EncryptedExtensions, Certificate, CertificateVerify y Finished; el cliente verifica y termina con su Finished. Estos casos usan autenticación de servidor por certificado e intercambio (EC)DHE; excluyen PSK, reanudación y 0-RTT. TLS 1.3 también permite PSK sin Certificate y secretos no efímeros, por lo que estas reglas no se universalizan.
| Elemento | Pregunta que responde |
|---|---|
| Certificate | ¿Qué identidad y clave pública presenta el servidor? |
| CertificateVerify | ¿Prueba que controla la clave privada? |
| Finished | ¿Confirma que ambas partes vieron el mismo handshake? |
Seis ejercicios
1. Certificado caducado
Un certificado encadena hasta una CA confiable, pero su periodo de validez ya terminó. ¿Debe aceptarse solo por la cadena? No. La validación incluye la validez temporal además de la cadena y la identidad esperada, conforme a RFC 5280 y las recomendaciones de identidad de RFC 9525.
2. Nombre distinto
El certificado es válido para api.ejemplo.es y el cliente conecta con www.ejemplo.es. ¿Basta una firma correcta? No. La identidad solicitada debe coincidir con el nombre autenticado; una clave legítima para otro nombre no prueba este servidor.
3. Clave pública no descifra “todo”
¿El cliente cifra todos los datos de aplicación con la clave pública del certificado? No como descripción de TLS 1.3. El intercambio de claves efímero permite derivar secretos simétricos de handshake y aplicación; el certificado participa en autenticación.
4. CertificateVerify
¿Qué evidencia aporta? Una firma sobre el contexto del handshake que verifica con la clave pública del certificado y demuestra posesión de la privada. No es la misma operación que cifrar el cuerpo HTTP.
5. Finished
Un atacante altera un mensaje negociado antes de Finished. ¿Qué control lo detecta? Finished, que usa datos derivados del secreto de handshake sobre el transcript. Si no coincide, la conexión no debe continuar como si ambas partes hubieran negociado lo mismo.
6. Reutilizar el certificado
Dos conexiones presentan el mismo certificado válido. ¿Comparten necesariamente la misma clave de tráfico? No. La autenticación del servidor puede ser la misma; las claves de sesión se derivan en cada handshake con material efímero y aleatorio.
Método de examen
Para cada afirmación, nombra primero la propiedad: identidad, posesión de clave, integridad del handshake o confidencialidad de datos. Después relaciona el mensaje: Certificate, CertificateVerify o Finished. Evita convertir “certificado” en respuesta automática a toda pregunta de cifrado.
El Pack Temario TAI 2027 reúne los 33 temas oficiales desarrollados y declara en su ficha qué incluyen sus test y simulacro; esta práctica solo trabaja seis decisiones de protocolo.
Preguntas frecuentes
¿TLS 1.3 cifra el certificado del servidor?
En el flujo TLS 1.3 el Certificate del servidor se envía después de que se establezcan claves de handshake, por lo que va protegido por esas claves.
¿Una firma digital y el cifrado son lo mismo?
No. La firma permite verificar autenticidad e integridad; el cifrado busca confidencialidad. TLS combina mecanismos distintos con finalidades distintas.
