Decodificador X.509

Decodificar certificados X.509
Entendiendo Certificados X.509
TL;DR

Los certificados X.509 son documentos digitales que vinculan una clave pública a una identidad. Son la base de TLS/SSL: cada conexión HTTPS los utiliza.

¿Qué es X.509?

X.509 es un estándar internacional (ITU-T X.509, también publicado como RFC 5280) que define el formato de los certificados de clave pública. Un certificado X.509 es un documento firmado digitalmente que vincula una clave pública a una identidad, como un nombre de dominio, una organización o un individuo. Los certificados son los anclajes de confianza de internet: cada conexión HTTPS, cada aplicación con firma de código y cada correo electrónico S/MIME depende de certificados X.509.

Cuando visita un sitio web a través de HTTPS, su navegador recibe el certificado X.509 del servidor, verifica que fue emitido por una Autoridad de Certificación (CA) de confianza, comprueba que no ha expirado ni sido revocado, y confirma que el nombre de dominio coincide. Solo después de que todas estas verificaciones se superan, el navegador establece una conexión cifrada.

El estándar X.509 fue publicado por primera vez en 1988 como parte de la especificación de servicios de directorio X.500. La versión actual (v3) introdujo extensiones, que permiten a los certificados transportar metadatos adicionales como Subject Alternative Names, restricciones de uso de clave e información de revocación. Los certificados versión 3 se usan universalmente hoy en día.

Estructura del certificado

Todo certificado X.509 v3 contiene los siguientes campos, codificados en formato ASN.1 DER y típicamente distribuidos en formato PEM (Base64 con armadura):

CampoDescripciónEjemplo
VersiónVersión del certificado (casi siempre v3)v3
Número de serieIdentificador único asignado por la CA03:A1:F2:...
Algoritmo de firmaAlgoritmo usado por la CA para firmarSHA256withRSA
EmisorNombre distinguido de la CA firmanteCN=Let's Encrypt Authority X3, O=Let's Encrypt
Validez (No antes)Inicio del período de validez del certificado2024-01-15T00:00:00Z
Validez (No después)Fin del período de validez del certificado2024-04-14T23:59:59Z
SujetoNombre distinguido del titular del certificadoCN=example.com
Clave públicaLa clave pública del sujeto y algoritmoRSA 2048-bit
ExtensionesExtensiones opcionales v3 (ver tabla abajo)SAN, Key Usage, etc.

Extensiones comunes

Las extensiones dan a los certificados X.509 v3 su flexibilidad. Algunas están marcadas como críticas (el certificado debe rechazarse si la extensión no es comprendida) y otras son no críticas.

ExtensiónOIDPropósito
Subject Alternative Name (SAN)2.5.29.17Lista identidades adicionales (nombres DNS, IPs, emails) para las que el certificado es válido
Key Usage2.5.29.15Restringe las operaciones criptográficas que la clave puede realizar (ej., digitalSignature, keyEncipherment)
Extended Key Usage (EKU)2.5.29.37Especifica propósitos como autenticación de servidor TLS, autenticación de cliente TLS o firma de código
Authority Key Identifier (AKI)2.5.29.35Identifica la clave pública de la CA que firmó este certificado
CRL Distribution Points2.5.29.31URLs donde puede descargarse la Lista de Revocación de Certificados
Authority Information Access (OCSP)1.3.6.1.5.5.7.1.1URL para verificaciones del Protocolo de Estado de Certificados en Línea y recuperación del certificado del emisor de la CA

Cadena de confianza

Los certificados X.509 no existen de forma aislada. Forman una cadena de confianza (también llamada cadena de certificados o ruta de certificación) desde el certificado de entidad final hasta una Autoridad de Certificación raíz de confianza.

X.509 Chain of Trust Three stacked certificates representing the chain of trust. The Root CA (self-signed, stored in OS/browser trust store) signs the Intermediate CA certificate, which in turn signs the Leaf certificate for the end-entity domain. Arrows indicate the signing relationship. Root CA Certificate Self-signed | Stored in OS/browser trust store Issuer = Subject (self-signed) signs Intermediate CA Certificate Issued by Root CA | Issues end-entity certs Issuer = Root CA, Subject = Intermediate CA signs Leaf (End-Entity) Certificate Your domain: example.com Issuer = Intermediate CA, Subject = example.com Trust direction

La cadena funciona de la siguiente manera:

  1. CA raíz: Un certificado autofirmado preinstalado en el almacén de confianza de su sistema operativo o navegador. Las CA raíz son los anclajes de confianza definitivos: se confía en ellas porque han sido verificadas e incluidas explícitamente por los proveedores de SO y navegadores (Apple, Microsoft, Mozilla, Google)

  2. CA intermedia: Un certificado firmado por la CA raíz (u otra intermedia). Las CA raíz rara vez firman certificados de entidad final directamente. En su lugar, delegan en intermedias, lo que limita la exposición: si una intermedia es comprometida, solo esa intermedia necesita ser revocada, no la raíz

  3. Certificado hoja (entidad final): El certificado presentado por el servidor (su sitio web). Está firmado por una CA intermedia y contiene la clave pública y el nombre(s) de dominio del servidor

Durante un handshake TLS, el servidor envía el certificado hoja y cualquier certificado intermedio. El cliente construye la cadena hasta una raíz de confianza y verifica cada firma en la ruta. Si algún eslabón está roto (expirado, revocado o firmado por una CA no confiable), la conexión falla.

Certificate Transparency

Certificate Transparency (CT) es un sistema de registros públicos, de solo adición, que registran cada certificado emitido por las CA participantes. CT permite a los propietarios de dominios y al público detectar certificados emitidos de forma incorrecta o fraudulenta. Desde 2018, Google Chrome requiere que todos los certificados de confianza pública estén registrados en al menos dos registros CT.

Casos de uso comunes

  • HTTPS / TLS: Todo sitio web seguro usa un certificado X.509 para demostrar su identidad y habilitar la comunicación cifrada. El navegador verifica la cadena de certificados antes de establecer la conexión TLS
  • Firma de código: Los desarrolladores de software firman ejecutables, controladores y paquetes con certificados X.509 para que los sistemas operativos y usuarios puedan verificar que el código no ha sido manipulado y proviene de un editor conocido
  • Firma y cifrado de correo (S/MIME): Los certificados X.509 permiten el cifrado de extremo a extremo del correo electrónico y las firmas digitales, demostrando la identidad del remitente y asegurando la integridad del mensaje
  • TLS mutuo (mTLS): En arquitecturas de confianza cero, tanto el cliente como el servidor presentan certificados para autenticarse mutuamente. Esto es común en la comunicación entre servicios dentro de arquitecturas de microservicios
  • Autenticación VPN: Las VPN empresariales usan certificados X.509 para la autenticación de clientes, reemplazando o complementando el inicio de sesión con usuario/contraseña
  • Firma de documentos: Las firmas digitales de PDF usan certificados X.509 para proporcionar no repudio: prueba de que el firmante firmó el documento y de que no ha sido alterado
  • Identidad de dispositivos IoT: Los dispositivos conectados usan certificados X.509 para autenticarse ante plataformas en la nube (AWS IoT, Azure IoT Hub), asegurando que solo dispositivos autorizados puedan conectarse

Prueba estos ejemplos

Certificado PEM válido Válido

Un certificado X.509 codificado en PEM con marcadores BEGIN/END. El contenido Base64 entre los marcadores codifica la estructura del certificado DER (binario) que contiene el sujeto, el emisor, la clave pública, el período de validez y las extensiones.

-----BEGIN CERTIFICATE----- MIIBkTCB+wIUEjRW...base64...== -----END CERTIFICATE-----
Certificado expirado Inválido

Un certificado PEM estructuralmente válido cuya fecha notAfter ha pasado. El decodificador analizará el certificado pero lo marcará como expirado. Los navegadores y clientes TLS rechazan certificados expirados para prevenir el uso de claves potencialmente comprometidas.

-----BEGIN CERTIFICATE----- MIIC...expired...== -----END CERTIFICATE-----