Validación de certificados en TLS

Sin la validación de certificados, podría establecerse una conexión TLS con un atacante que se hiciera pasar por el servidor (man-in-the-middle). La validación de certificados garantiza que se está comunicando con el servidor legítimo que controla la clave privada.

Campos clave: Subject (quién posee el certificado), SubjectAltName (nombres DNS/IP), Issuer (CA firmante), Validity (notBefore/notAfter), Public Key, Signature. El navegador comprueba todos estos campos.

Certificado del servidor → certificado de CA intermedia → certificado de CA raíz. La CA raíz está autofirmada y viene preinstalada en el almacén de confianza del sistema operativo o del navegador. El servidor envía su certificado y los certificados intermedios en el mensaje Certificate del handshake TLS.

Cada certificado está firmado por el emisor que se encuentra por encima de él. El cliente verifica: signature(cert_n) mediante public_key(cert_{n+1}). Si alguna firma no es válida, se rechaza la cadena. La raíz se considera de confianza porque está preinstalada, no por su firma.

El cliente comprueba que el nombre de host del servidor coincida con Subject o SubjectAltName (entradas DNS) del certificado. Los comodines (*.example.com) coinciden con una sola etiqueta. Desde 2000, SAN tiene prioridad sobre CN para la coincidencia del nombre de host.

El cliente comprueba notBefore ≤ now ≤ notAfter para cada certificado de la cadena. Los certificados caducados se rechazan aunque sus firmas sean válidas. La duración de los certificados se ha reducido: ahora los navegadores la limitan a ~398 días.

La CA publica una Certificate Revocation List (CRL), una lista firmada de los números de serie de los certificados revocados. El cliente descarga la URL de la CRL (de la extensión CRL Distribution Points del certificado) y comprueba si contiene el número de serie.

Online Certificate Status Protocol (OCSP) permite que los clientes consulten al respondedor OCSP de la CA para conocer el estado de un único certificado. Es más rápido que una CRL, pero añade latencia. OCSP Stapling hace que el servidor incluya una respuesta OCSP firmada en el handshake TLS.

CT (RFC 6962) exige que las CA registren todos los certificados emitidos en registros públicos en los que solo se pueden añadir entradas. Los navegadores comprueban la presencia de Signed Certificate Timestamps (SCT) en el certificado o en una extensión TLS. Esto evita que las emisiones indebidas pasen inadvertidas.

HTTP Public Key Pinning (HPKP, obsoleto) y el certificate pinning en aplicaciones móviles fijan una clave pública específica o el hash de un certificado. Si el servidor presenta un certificado diferente, la conexión se rechaza aunque sea válido; así se evitan ataques por compromiso de una CA.

ERR_CERT_AUTHORITY_INVALID: la raíz no es de confianza. ERR_CERT_DATE_INVALID: certificado caducado. ERR_CERT_COMMON_NAME_INVALID: el nombre de host no coincide. NET::ERR_CERT_REVOKED: OCSP/CRL indica que el certificado está revocado. Cada error corresponde al fallo de un paso de validación específico.

¿Qué consigue OCSP Stapling?

La validación de certificados en TLS incluye la verificación de la cadena, la comprobación de firmas, la coincidencia de nombres, los períodos de validez y la revocación. A continuación: ataques históricos contra TLS y cómo los mitiga TLS 1.3.