X.509

Certificado Digital X.509
Última versión	v3 / mayo de 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).^[1]​ 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 a partir de la norma X.500,^[2]​ 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 RFC520.

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.^[3]​
• 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".^[4]​
• En 2019, Corey Bonnel dio cuenta de la emisión de certificados cuyo número de serie era de un largo de 63 bits,^[5]​ mientras que la RFC 5280 especifica un mínimo de 64 bits (entero positivo).^[6]​ 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.^[7]​ 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.

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

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:^[8]​

• 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),^[6]​ 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:^[9]​

• .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=[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 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=[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.^[10]​

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
• Sellado de tiempo confiable

Referencias

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

1. Talens-oliag, Sergio. (html). Universitat de València. Archivado desde el original el 30 de junio de 2004. Consultado el 14 de marzo de 2019. «El formato de certificados X.509 es un estándar del ITU-T (International Telecommunication Union-Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization / International Electrotechnical Commission) que se publicó por primera vez en 1988. El formato de la versión 1 fue extendido en 1993 para incluir dos nuevos campos que permiten soportar el control de acceso a directorios. Después de emplear el X.509 v2 para intentar desarrollar un estándar de correo electrónico seguro, el formato fue revisado para permitir la extensión con campos adicionales, dando lugar al X.509 v3, publicado en 1996.» 
2. Nojed, Nik (9 de enero de 2018). (html). SSL Authority (en inglés). Archivado desde el original el 23 de febrero de 2019. Consultado el 14 de marzo de 2019. «The certificate was created in 1988 as part of the X.500 directory that helped early users navigate digital networking directories.» 
3. Lenstra, Arjen; Weger, Benne de (4 de julio de 2005). (pdf). Tue (en inglés). Archivado desde el original el 25 de noviembre de 2005. Consultado el 14 de marzo de 2019. «A certificate, such as an X.509 or PGP certificate, is a highly structured document, andalso executable code will have a lot of structure to be able to execute properly. Nevertheless,both these data structures may contain pieces of data that look random, and may have beenconstructed to fit a hash collision.» 
4. Stevens, Marc; Lenstra, Arjen; Weger, Benne de (30 de noviembre de 2007). (html). Tue (en inglés). Archivado desde el original el 13 de diciembre de 2007. Consultado el 14 de marzo de 2019. «We announce two different Win32 executable files with different functionality but identical MD5 hash values. This shows that trust in MD5 as a tool for verifying software integrity, and as a hash function used in code signing, has become questionable.» 
5. DarkMatter Concerns
6. Caudill, Adam (9 de marzo de 2019). (html) (en inglés). Archivado desde el original el 13 de marzo de 2019. Consultado el 14 de marzo de 2019. «A popular software package for CAs, EJBCA had a default of using 64-bit serial numbers, and used the second strategy for dealing with CSPRNG output with the high bit set. This means that instead of using the full 64-bit output, it effectively reduced it to 63 bits – cutting the number of possible values in half. When we are talking about numbers this large, it’s easy to think that 1 bit wouldn’t make much difference, but the difference between 2^64 and 2^63 is substantial – to be specific, 2^63 is off by over 9 quintillion or more specifically 9,223,372,036,854,775,808.» 
7. Cimpanu, Catalin (13 de marzo de 2019). (html). ZDNet (en inglés). Archivado desde el original el 14 de marzo de 2019. Consultado el 14 de marzo de 2019. «Multiple CAs have misissued over 1.2 million TLS certs with weak 63-bit serial numbers, instead of the standard of 64 bits.» 
8. (html). Oracle Corporation (en inglés). 12 de mayo de 2013. Archivado desde el original el 12 de mayo de 2013. Consultado el 14 de marzo de 2019. 
9. (html). Red Hat (en inglés). 20 de diciembre de 2015. Archivado desde el original el 20 de diciembre de 2015. Consultado el 14 de marzo de 2019. «An X.509 v3 certificate contains an extension field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates.» 
10. (html). Eurologic. Archivado desde digitales.htm el original el 16 de enero de 2003. Consultado el 14 de marzo de 2019. 

Enlaces externos

• CAcert.org, Entidad Certificadora administrada por la comunidad
• Certificados de Prueba
• Safelayer (implementación comercial)
• , asistente para certificados SSL autofirmados.

•   Datos: Q1065865