X.509

Su sintaxis, se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One), y los formatos de codificación más comunes son DER (Distinguish Encoding Rules) o PEM (Privacy Enhanced Mail).

X.509 fue publicado oficialmente en 1988 a partir de la norma X.500,​ y asume un sistema jerárquico estricto de autoridades certificadoras (ACs) encargadas de emitir certificados. Esto contrasta con modelos de redes de confianza, como PGP, donde cualquier nodo de la red (no solo las ACs) puede firmar claves públicas, y por ende avalar la validez de certificados de claves de otros. La versión 3 de X.509 incluye la flexibilidad de soporte de otras tecnologías como pasarelas de red y redes en malla. Puede usarse en una red peer to peer confiable de tipo OpenPGP, pero desde 2004 raramente se usa allí.

El sistema X.500 nunca se implementó completamente, y el grupo de trabajo de la infraestructura de clave pública de la IETF, comúnmente conocido como PKIX para «infraestructura de clave pública (X.509)» o PKIX, adaptó el estándar a la estructura más flexible de Internet. X.509 incluye también estándares para implementación de listas de certificados en revocación (CRLs), y con frecuencia aspectos de sistemas PKI. De hecho, el término «certificado X.509» se refiere comúnmente al Certificado PKIX y Perfil CRL del certificado estándar de X.509 v3 de la IETF, como se especifica en la RFC5280.

La forma aprobada por la IETF de comprobar la validez de un certificado es el Online Certificate Status Protocol (OCSP).

• En 2005, Arjen Lenstra y Benne de Weger demostraron como usar colisiones de hash para construir certificados que contienen firmas idénticas y que solo difieren en la clave pública, lo cual alcanzaron usando un ataque de colisiones en la función de hash MD5.​
• En 2007, Marc Stevens, Arjen Lenstra y Benne de Weger demostraron cómo usar colisiones de hash para añadir sufijos a dos ficheros diferentes obteniendo firmas idénticas.​
• En 2019, Corey Bonnel dio cuenta de la emisión de certificados con números de serie de 63 bits,​ mientras que la RFC 5280 especifica un mínimo de 64 bits (entero positivo).​ Esto trajo como consecuencia la revocación de entre 1 800 000 y 2 000 000 de certificados de empresas tales como Apple, Google, GoDaddy y otros se hayan visto forzados a revocarlos de manera progresiva.​ Si bien no representa mayor riesgo en lo que respecta a la seguridad, da cuenta de una falla que indica una verificación no exhaustiva de dichos documentos digitales.

Una autoridad de certificación (AC) es una entidad que emite certificados digitales para su uso por terceros. Es un ejemplo de un tercero de confianza. Las ACs son características en muchos esquemas de infraestructuras de clave pública (PKI).

Los certificados raíz de confianza de una organización pueden distribuirse a todos los empleados de manera que ellos puedan usar el sistema de infraestructura de clave pública de la compañía. Navegadores web como Internet Explorer, Netscape/Mozilla y Opera vienen con certificados raíz pre-instalados, de manera que certificados SSL de grandes vendedores que hayan pagado por el privilegio de ser pre-instalados funcionen al instante. En efecto, el propietario del navegador web determina qué ACs son terceros de confianza para los usuarios del navegador web. A pesar de que estos certificados raíz pueden borrarse o deshabilitarse, es muy raro que los usuarios lo hagan.

Existen muchas ACs comerciales que cobran por sus servicios. Instituciones y gobiernos pueden tener sus propias ACs y también existen ACs gratuitas.

En el sistema X.509, una autoridad certificadora (AC) emite un certificado asociando una clave pública a un Nombre Distinguido particular en la tradición de X.500 o a un Nombre Alternativo tal como una dirección de correo electrónico o una entrada de DNS.

Estructura de un certificado

La estructura de un certificado digital X.509 v3 es la siguiente:​

• Certificado
  • Versión
  • Número de serie del certificado
  • ID del algoritmo utilizado por el CA para firmar (típicamente RSA o DSA)
  • Emisor (CA)
  • Validez
    • No antes de
    • No después de
  • Sujeto, (sujeto titular) expresado en notación DN (Distinguished Name), compuesto por CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). El sujeto puede ser una persona, un servidor o un servicio.
  • Información de clave pública del sujeto
    • Algoritmo de clave pública
    • Clave pública del sujeto
  • Identificador único de emisor (opcional)
  • Identificador único de sujeto (opcional)
  • Extensiones (opcional)
    • ...
• Algoritmo usado para firmar el certificado
• Firma digital del certificado

Los identificadores únicos de emisor y sujeto fueron introducidos en la versión 2, y las extensiones en la versión 3. Obsérvese que el número de serie debe ser único para cada certificado emitido por una misma autoridad certificadora (tal como lo indica el RFC 2459) y ser un número entero positivo con un mínimo de 64 bits (tal como lo indica el RFC 5280),​ aunque hoy en día hay Autoridades Certificadoras que usan 72 bits o más para tal tarea.

X.509 es la pieza central de la infraestructura de clave pública y es la estructura de datos que enlaza la clave pública con los datos que permiten identificar al titular. Su sintaxis se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One) y los formatos de codificación más comunes son DER (Distinguished Encoding Rules) o PEM (Privacy-enhanced Electronic Mail). Siguiendo la notación de ASN.1, un certificado contiene diversos campos, agrupados en tres grandes grupos:

• El primer campo es el subject (sujeto), que contiene los datos que identifican al sujeto titular. Estos datos están expresados en notación DN (Distinguished Name), donde un DN se compone a su vez de diversos campos, siendo los más frecuentes los siguientes; CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). Un ejemplo para identificar un usuario mediante el DN, es el siguiente: CN=David.comin O=Safelayer, OU=development, C=ES. Además del nombre del sujeto titular (subject), el certificado, también contiene datos asociados al propio certificado digital, como la versión del certificado, su identificador (serialNumber), la CA firmante (issuer), el tiempo de validez (validity), etc. La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL y de la CA,etc.).

• En segundo lugar, el certificado contiene la clave pública, que expresada en notación ASN.1, consta de dos campos, en primer lugar, el que muestra el algoritmo utilizado para crear la clave (ej. RSA), y en segundo lugar, la propia clave pública.

• Por último, la CA, ha añadido la secuencia de campos que identifican la firma de los campos previos. Esta secuencia contiene tres atributos, el algoritmo de firma utilizado, el hash de la firma, y la propia firma digital.

Extensiones de archivo de certificados

Las extensiones de archivo de certificados X.509 son:​

• .CER - Certificado codificado en CER (Canonical Encoding Rules), algunas veces es una secuencia de certificados
• .DER - Certificado codificado en DER (Distinguished Encoding Rules)
• .PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----"
• .P7B - Ver .p7c
• .P7C - Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s)
• .PFX - Ver .p12
• .P12 - PKCS#12, puede contener certificado(s) (público) y claves privadas (protegido con clave)

PKCS #7 es un estándar para firmar o cifrar datos (ellos lo llaman "sobreado"). Dado que el certificado es necesario para verificar datos firmados, es posible incluirlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar.

PKCS #12 evolucionó del estándar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos públicos y privados dentro de un archivo.

Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las líneas BEGIN/END apropiadas.

Ejemplo de certificado X.509 y del proceso de validación

Como ejemplo de un certificado X.509, se encuentra aquí una decodificación (generada con OpenSSL) de uno de los certificados viejos de www.freesoft.org. El certificado real tiene un tamaño de alrededor de 1 KB. Fue emitido (firmado) por Thawte (desde que fue adquirido por Verisign), tal como se indica en el campo Emisor. El tema contiene bastante información personal, pero la parte más importante es el nombre común (CN) de www.freesoft.org - esta es la parte que debe coincidir con la terminal que se está autenticando. A continuación viene una clave pública RSA (módulo y exponente público), seguido de la firma, computada tomando un hash MD5 de la primera parte del certificado y cifrándola con la clave privada RSA de Thawte.

Certificate:    Data:        Version: 1 (0x0)        Serial Number: 7829 (0x1e95)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/[email protected]        Validity            Not Before: Jul  9 16:04:02 1998 GMT            Not After : Jul  9 16:04:02 1999 GMT        Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,                 OU=FreeSoft, CN=www.freesoft.org/[email protected]        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:                    33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:                    66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:                    70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:                    16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:                    c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:                    8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:                    d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:                    e8:35:1c:9e:27:52:7e:41:8f                Exponent: 65537 (0x10001)    Signature Algorithm: md5WithRSAEncryption        93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:        92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:        ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:        d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:        0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:        5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:        8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:        68:9f 

Obsérvese que al final del certificado se encuentra la firma del mismo. Para estampar esta firma, la autoridad certificadora calcula un hash MD5 de la primera parte del certificado (la sección de Data: los datos del mismo más la clave pública) y cifra ese hash con su clave privada, que mantiene en secreto. Ahora supongamos que un cliente se conecta a www.freesoft.org y el sitio le devuelve el certificado anterior, con la intención de probar su identidad. Para validar este certificado, necesitamos el certificado de la autoridad certificadora, que fue el emisor del primero (Thawte Server CA). Se toma la clave pública del certificado de la autoridad certificadora para decodificar la firma del primer certificado, obteniéndose un hash MD5. Este hash MD5 debe coincidir con el hash MD5 calculado sobre la primera parte del certificado. En ese caso el proceso de validación termina con éxito. Si no, la validación no tiene éxito, y no puede asegurarse que el certificado de www.freesoft.org está vinculado con esa clave pública. Dicho de otro modo, es posible que www.freesoft.org no sea quien dice ser. A continuación se muestra el certificado de la CA:

Certificate:    Data:        Version: 3 (0x2)        Serial Number: 1 (0x1)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/[email protected]        Validity            Not Before: Aug  1 00:00:00 1996 GMT            Not After : Dec 31 23:59:59 2020 GMT        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                 OU=Certification Services Division,                 CN=Thawte Server CA/[email protected]        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:                    68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:                    85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:                    6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:                    6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:                    29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:                    6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:                    5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:                    3a:c2:b5:66:22:12:d6:87:0d                Exponent: 65537 (0x10001)        X509v3 extensions:            X509v3 Basic Constraints: critical                CA:TRUE    Signature Algorithm: md5WithRSAEncryption        07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:        a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:        3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:        4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:        8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:        e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:        b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:        70:47 

Este es un ejemplo de un certificado auto firmado. Nótese que el CN del Emisor y el CN del Sujeto son iguales. No hay forma de verificar este certificado, salvo que se comprueba contra sí mismo. En este caso, hemos alcanzado el fin de la cadena de certificados. ¿Cómo es entonces que este certificado se hace confiable? Simple: se configura manualmente. Thawte es una de las autoridades certificantes raíz reconocida por Microsoft y Netscape. Este certificado ya viene con el navegador web (probablemente pueda encontrarse listado como "Thawte Server CA" en las opciones de seguridad) y es confiable por defecto. Como certificado confiado globalmente de larga vida (nótese la fecha de vencimiento) que puede firmar prácticamente cualquier cosa (nótese la falta de limitaciones), su clave privada correspondiente debe ser una de las más ocultas del mundo.

Hay distintos tipos de certificados, según el criterio que utilicemos de clasificación.​

Verificación de datos

• Certificados de Clase 1: corresponde a los certificados más fáciles de obtener e involucran pocas verificaciones de los datos que figuran en él: sólo el nombre y la dirección de correo electrónico del titular.
• Certificados de Clase 2: en los que la Autoridad Certificadora comprueba además el Documento de identidad o permiso de conducir que incluya fotografía, el número de la Seguridad Social y la fecha de nacimiento.
• Certificados de Clase 3: en la que se añaden a las comprobaciones de la Clase 2 la verificación de crédito de la persona o empresa mediante un servicio del tipo Equifax, Datacredito.
• Certificados de Clase 4: que a todas las comprobaciones anteriores suma la verificación del cargo o la posición de una persona dentro de una organización.

Finalidad

• Certificados SSL para cliente: mediante el protocolo Secure Socket Layer, dirigido a una persona física.
• Certificados SSL para servidor: usados para identificar a un servidor ante un cliente en comunicaciones mediante SSL.
• Certificados S/MIME : usados para servicios de correo electrónico firmado y cifrado, que se expiden generalmente a una persona física.
• Certificados para la firma de código: usados para identificar al autor de ficheros o porciones de código en cualquier lenguaje de programación que se deba ejecutar en red (Java, JavaScript, CGI, etc).
• Certificados para AC (Autoridades Certificadoras): se usa por el software cliente para determinar si pueden confiar en un certificado cualquiera, accediendo al certificado de la AC y comprobando que ésta es de confianza.

• Autoridad de certificación
• Certificado digital
• Clave pública
• CRL
• Firma digital
• Infraestructura de clave pública (PKI)
• Online Certificate Status Protocol (OCSP)
• PGP
• Sellado de tiempo confiable

• Estudio y propuesta de una guía de sintonización de servicios web seguros basados en J2EE. David Comín Roig UPC.

• CAcert.org, Entidad Certificadora administrada por la comunidad
• Albalia Demo CA Certificados de Prueba
• Integración corporativa de la confianza (Enterprise Trust Integration), estándares de Servicios Web y demos
• Safelayer (implementación comercial)
• Xcarecrows 4 X509 (implementación comercial)
• SeSeLe, asistente para certificados SSL autofirmados.