Estructura de los certificados X.509

Un certificado X.509 es un documento digital estandarizado que vincula una clave pública con una identidad. El estándar X.509 (definido en RFC 5280) especifica el formato, los campos y las extensiones utilizados en los certificados digitales de todo el mundo. Todos los certificados TLS/HTTPS, los certificados de correo electrónico S/MIME, los certificados de firma de código y los certificados de autenticación de cliente siguen el formato X.509. Comprender la estructura de un certificado X.509 le ayuda a leer la información del certificado, diagnosticar errores de certificados y tomar decisiones fundamentadas sobre la implementación y validación de certificados.

Los primeros campos de un certificado X.509 establecen su identidad básica. Versión: X.509 v3 es el estándar actual (v3 añadió extensiones). Número de serie: entero único asignado por la CA emisora que identifica este certificado específico; se utiliza en las CRL (listas de revocación) para revocar certificados individuales. Algoritmo de firma: especifica el algoritmo utilizado por la CA para firmar el certificado (por ejemplo, sha256WithRSAEncryption o ecdsa-with-SHA256). Este campo aparece dos veces: una en TBSCertificate y otra en el contenedor de firma externo; ambos deben coincidir.

Dos de los campos más importantes de un certificado establecen las partes implicadas. El campo Issuer identifica la CA que firmó el certificado (por ejemplo, CN=DigiCert Global CA G2, O=DigiCert Inc, C=US). El campo Subject identifica la entidad a la que se emitió el certificado (por ejemplo, CN=*.example.com, O=Example Corp, C=US). En un certificado TLS, el Common Name (CN) del Subject o la extensión Subject Alternative Name (SAN) especifica para qué nombre o nombres de dominio es válido el certificado. Los navegadores comparan el nombre de host solicitado con estos campos.

El periodo de validez define cuándo está activo el certificado. Consta de dos marcas de tiempo: notBefore (el certificado aún no es válido antes de esta fecha) y notAfter (el certificado ha caducado después de esta fecha). Los clientes TLS verifican que la hora actual se encuentre dentro de este intervalo. Los certificados presentados fuera de su periodo de validez provocan un error de certificado en los navegadores y deben renovarse. La práctica recomendada actual es emitir certificados de corta duración (90 días, como hace Let's Encrypt) para limitar la exposición si una clave privada se ve comprometida entre la emisión y la caducidad.

La carga útil principal del certificado es el campo Subject Public Key Info, que contiene la clave pública que se certifica y especifica el algoritmo con el que se utiliza. En un certificado RSA, este campo contiene el módulo y el exponente de la clave pública RSA, junto con su longitud en bits (2048, 4096). En un certificado ECC, contiene el nombre de la curva (por ejemplo, prime256v1) y el punto de la clave pública. La CA no genera este par de claves: el solicitante del certificado genera su propio par de claves y envía únicamente la clave pública en una Certificate Signing Request (CSR).

X.509 v3 introdujo extensiones que amplían considerablemente las capacidades de los certificados. Las extensiones pueden ser críticas (un cliente que no pueda procesarlas debe rechazar el certificado) o no críticas (pueden ignorarse si no se comprenden). Entre las extensiones principales se incluyen: Subject Alternative Name (SAN): nombres de dominio o direcciones IP adicionales que cubre el certificado; Key Usage: restringe las operaciones para las que puede utilizarse la clave (firma digital, cifrado de claves); Extended Key Usage: restringe aún más el propósito (autenticación de servidor TLS, autenticación de cliente, firma de código); y Basic Constraints: indica si el Subject es una CA.

Históricamente, el campo Common Name (CN) del campo distintivo Subject se utilizaba para el nombre de dominio principal. Los certificados modernos utilizan Subject Alternative Names (SAN), ya que los navegadores dejaron de admitir la comparación basada en CN (RFC 2818) en favor de SAN. Los SAN permiten que un único certificado cubra varios dominios (certificados multi-SAN) o todos los subdominios de un dominio (certificados comodín: *.example.com). Los comodines SAN solo cubren un nivel: *.example.com cubre www.example.com, pero no sub.www.example.com.

Dos extensiones importantes indican a los clientes cómo comprobar si un certificado ha sido revocado antes de su fecha de caducidad. CRL Distribution Points (CDP): contiene las URL desde las que se puede descargar la lista de revocación de certificados de la CA. Authority Information Access (AIA): contiene la URL del respondedor OCSP (Online Certificate Status Protocol) de la CA para comprobar la revocación en tiempo real. Los clientes modernos prefieren OCSP a las descargas de CRL porque las CRL pueden ser archivos grandes. La firma digital de la CA en las respuestas OCSP garantiza que los clientes reciban información auténtica sobre el estado de revocación.

Los certificados X.509 se presentan en varios formatos de codificación que encontrará en la práctica. PEM (Privacy Enhanced Mail): DER codificado en base64 y delimitado por las cabeceras -----BEGIN CERTIFICATE-----. Es legible para las personas y se utiliza en Linux/Apache/nginx. DER (Distinguished Encoding Rules): formato binario. Se utiliza en aplicaciones Java y en algunos contextos de Windows. PFX/PKCS#12: formato contenedor que agrupa el certificado, su cadena y la clave privada en un único archivo protegido con contraseña. Se utiliza en Windows IIS y al exportar certificados con sus claves privadas. P7B/PKCS#7: contiene únicamente la cadena de certificados, sin clave privada, y se utiliza en los almacenes de certificados de Windows.

Certificate Transparency (CT) es un marco que exige a las CA registrar todos los certificados emitidos en registros auditables públicamente. Esto permite que cualquiera supervise la emisión de certificados no autorizados para sus dominios. Chrome y Safari exigen la inclusión en registros CT para los certificados TLS. SCT (Signed Certificate Timestamp) es una prueba de inclusión en el registro, integrada en el certificado o entregada mediante una extensión TLS. Los registros CT permiten detectar rápidamente las emisiones incorrectas: si una CA emite por error un certificado para su dominio, lo verá en registros como crt.sh antes de que los atacantes puedan aprovecharlo.

El último componente de un certificado X.509 es la firma digital de la CA. La CA calcula un hash de todos los datos del certificado (TBSCertificate) y firma ese hash con su propia clave privada. Esta firma es lo que hace confiable al certificado: cualquiera puede verificarla utilizando la clave pública de la CA (que se encuentra en el propio certificado de la CA). El algoritmo de firma utilizado (indicado en el campo de firma) debe coincidir con el especificado anteriormente en el certificado. Cualquier modificación del certificado después de la firma invalida la firma y garantiza la integridad del certificado.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) de esta lección.

En esta lección ha aprendido lo siguiente: un certificado X.509 contiene versión, número de serie, emisor, sujeto, periodo de validez, clave pública y extensiones v3; la extensión SAN controla los nombres de host que cubre el certificado; las extensiones CDP y AIA apuntan a los puntos de conexión para comprobar la revocación; y los registros CT proporcionan historiales de auditoría públicos de la emisión de certificados. A continuación, exploraremos el ciclo de vida y la revocación de certificados.