X.509

Certificado Digital X.509
Última versión	v3 / Mayo 2008
sistema operativo	Todos
Género	Criptografía e infraestructura PKI
Licencia	estándar
Sitio Web	http://tools.ietf.org/rfc/rfc5280.txt

En criptografía, X.509 es un estándar UIT-T para infraestructuras de claves públicas (en inglés, Public Key Infrastructure o PKI). X.509 especifica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación. 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).

Historia y uso

X.509 fue publicado oficialmente en 1988 y comenzado conjuntamente con el estándar X.500 y asume un sistema jerárquico estricto de autoridades certificantes (ACs) para emisión de 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 bridges y mallas. Puede usarse en una web de confianza peer to peer de tipo OpenPGP, pero desde 2004 raramente se usa así.

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 RFC 3280.

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

Seguridad

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. [1]

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" [2]

Autoridad de certificación

Artículo principal: Autoridad de certificación

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 pre-instalados con certificados raíz, 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.

Certificados

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
  • ID del algoritmo
  • Emisor
  • Validez
    • No antes de
    • No después de
  • Sujeto
  • 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).

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, algunas veces es una secuencia de certificados
• .DER - Certificado codificado en DER
• .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 incluírlos 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=[e-mail]
       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=[e-mail]
       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 de 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=[e-mail]
       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=[e-mail]
       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.

Tipos de certificados

Hay distintos tipos de certificados, según el criterio que utilicemos de clasificación.^[1]

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.

Véase también

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

Enlaces externos

• 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)

Referencias

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

Notas al pie

1. ↑ http://www.eurologic.es/conceptos/certificados%20digitales.htm