En criptografía , X.509 es un estándar de la Unión Internacional de Telecomunicaciones (UIT) que define el formato de los certificados de clave pública . [1] Los certificados X.509 se utilizan en muchos protocolos de Internet, incluido TLS/SSL , que es la base de HTTPS , [2] el protocolo seguro para navegar por la web . También se utilizan en aplicaciones fuera de línea, como firmas electrónicas . [3]
Un certificado X.509 vincula una identidad a una clave pública mediante una firma digital. Un certificado contiene una identidad (un nombre de host, una organización o un individuo) y una clave pública ( RSA , DSA , ECDSA , ed25519 , etc.) y está firmado por una autoridad certificadora o autofirmado. Cuando un certificado está firmado por una autoridad certificadora de confianza, o validado por otros medios, alguien que posea ese certificado puede utilizar la clave pública que contiene para establecer comunicaciones seguras con otra parte, o validar documentos firmados digitalmente con la clave privada correspondiente .
X.509 también define listas de revocación de certificados , que son un medio para distribuir información sobre los certificados que una autoridad firmante ha considerado inválidos, así como un algoritmo de validación de ruta de certificación , que permite que los certificados sean firmados por certificados de CA intermedia, que son, a su vez, firmados por otros certificados, alcanzando eventualmente un ancla de confianza .
X.509 está definido por el "Sector de Estandarización" de la UIT ( UIT-T 's SG17 ), en la Comisión de Estudio 17 del UIT-T y se basa en la Notación de Sintaxis Abstracta Uno (ASN.1), otro estándar del UIT-T.
X.509 se publicó inicialmente el 3 de julio de 1988 y se inició en asociación con el estándar X.500 . Las primeras tareas fueron proporcionar a los usuarios acceso seguro a los recursos de información y evitar un ataque criptográfico de intermediario . Asume un estricto sistema jerárquico de autoridades certificadoras (CA) para emitir los certificados. Esto contrasta con los modelos de red de confianza , como PGP , donde cualquiera (no sólo las CA especiales) puede firmar y así dar fe de la validez de los certificados de clave de otros.
La versión 3 de X.509 incluye la flexibilidad para admitir otras topologías como puentes y mallas . [2] Puede usarse en una red de confianza peer-to-peer, similar a OpenPGP , [ cita necesaria ] pero rara vez se usaba de esa manera a partir de 2004 [actualizar]. El sistema X.500 sólo ha sido implementado por naciones soberanas [ ¿cuáles? ] para fines de cumplimiento del tratado de intercambio de información de identidad estatal, y el grupo de trabajo de Infraestructura de clave pública (X.509) (PKIX) del IETF ha adaptado el estándar a la organización más flexible de Internet. De hecho, el término certificado X.509 generalmente se refiere al certificado PKIX del IETF y al perfil CRL del estándar de certificado X.509 v3, como se especifica en RFC 5280, comúnmente llamado PKIX para infraestructura de clave pública (X.509) . [4]
Uno de los primeros problemas con la infraestructura de clave pública (PKI) y los certificados X.509 fue el conocido problema de "qué directorio". El problema es que el cliente no sabe dónde buscar los certificados intermedios que faltan porque el directorio global X.500 nunca se materializó. El problema se mitigó al incluir todos los certificados intermedios en una solicitud. Por ejemplo, los primeros servidores web solo enviaban el certificado del servidor web al cliente. Los clientes que carecían de un certificado de CA intermedio o de dónde encontrarlo no pudieron crear una ruta válida desde la CA hasta el certificado del servidor. Para solucionar el problema, los servidores web ahora envían todos los certificados intermedios junto con el certificado del servidor web. [5]
Si bien PKIX se refiere al estándar PKI del IETF o de Internet, existen muchas otras PKI con políticas diferentes. Por ejemplo, el gobierno de EE. UU. tiene su propia PKI con sus propias políticas, y CA/Browser Forum tiene su propia PKI con sus propias políticas. El PKI del gobierno de EE.UU. es un libro enorme de más de 2.500 páginas. Si la PKI de una organización difiere demasiado de la del IETF o CA/Browser Forum, entonces la organización corre el riesgo de perder interoperabilidad con herramientas comunes como navegadores web , cURL y Wget . Por ejemplo, si una PKI tiene la política de emitir certificados únicamente los lunes, las herramientas comunes como cURL y Wget no aplicarán la política y permitirán la emisión de un certificado los martes. [5]
Los certificados X.509 vinculan una identidad a una clave pública mediante una firma digital. En el sistema X.509 existen dos tipos de certificados. El primero es un certificado de CA. El segundo es un certificado de entidad final. Un certificado de CA puede emitir otros certificados. El certificado de CA autofirmado de nivel superior a veces se denomina certificado de CA raíz. Otros certificados de CA se denominan certificados de CA intermedia o certificados de CA subordinada. Un certificado de entidad final identifica al usuario, como una persona, organización o empresa. Un certificado de entidad final no puede emitir otros certificados. Un certificado de entidad final a veces se denomina certificado hoja, ya que no se pueden emitir otros certificados debajo de él.
Una organización que desea un certificado firmado solicita uno a una CA utilizando un protocolo como Solicitud de firma de certificado (CSR) , Protocolo simple de inscripción de certificados (SCEP) o Protocolo de administración de certificados (CMP) . La organización primero genera un par de claves , mantiene la clave privada en secreto y la utiliza para firmar la CSR. El CSR contiene información que identifica al solicitante y la clave pública del solicitante que se utiliza para verificar la firma del CSR y el nombre distinguido (DN) que es único para la persona, organización o empresa. El CSR puede ir acompañado de otras credenciales o pruebas de identidad requeridas por la autoridad certificadora.
La CSR se validará mediante una autoridad de registro (RA) y luego la autoridad de certificación emitirá un certificado que vincula una clave pública a un nombre distinguido en particular . Las funciones de autoridad de registro y autoridad de certificación suelen ser unidades de negocio independientes con separación de funciones para reducir el riesgo de fraude.
Los certificados raíz confiables de una organización se pueden distribuir a todos los empleados para que puedan utilizar el sistema PKI de la empresa. Navegadores como Internet Explorer , Firefox , Opera , Safari y Chrome vienen con un conjunto predeterminado de certificados raíz preinstalados, por lo que los certificados SSL de las principales autoridades certificadoras funcionarán instantáneamente; de hecho, los desarrolladores de los navegadores determinan qué CA son terceros de confianza para los usuarios de los navegadores. Por ejemplo, Firefox proporciona un archivo CSV y/o HTML que contiene una lista de CA incluidas. [8]
X.509 y RFC 5280 también incluyen estándares para implementaciones de listas de revocación de certificados (CRL). Otra forma aprobada por el IETF de comprobar la validez de un certificado es el Protocolo de estado de certificados en línea (OCSP). Firefox 3.0 habilitó la comprobación OCSP de forma predeterminada, al igual que las versiones de Windows desde al menos Vista y posteriores. [9]
La estructura prevista por los estándares se expresa en un lenguaje formal, la Notación de Sintaxis Abstracta Uno (ASN.1).
La estructura de un certificado digital X.509 v3 es la siguiente:
El campo Extensiones, si está presente, es una secuencia de una o más extensiones de certificado. [10] Cada extensión tiene su propio ID único, expresado como identificador de objeto (OID) , que es un conjunto de valores, junto con una indicación crítica o no crítica. Un sistema que utiliza un certificado debe rechazar el certificado si encuentra una extensión crítica que no reconoce o una extensión crítica que contiene información que no puede procesar. Una extensión no crítica puede ignorarse si no se reconoce, pero debe procesarse si se reconoce. [11]
La estructura de la versión 1 se proporciona en RFC 1422.
El formato interno de los identificadores únicos de emisor y sujeto especificados en X.520 El directorio: recomendación de tipos de atributos seleccionados.
El UIT-T introdujo identificadores únicos de emisor y sujeto en la versión 2 para permitir la reutilización del nombre del emisor o del sujeto después de algún tiempo. Un ejemplo de reutilización será cuando una CA quiebra y su nombre es eliminado de la lista pública del país. Después de un tiempo, es posible que se registre otra CA con el mismo nombre, aunque no esté relacionada con la primera. Sin embargo, el IETF recomienda que no se reutilicen los nombres de emisor ni de sujeto. Por lo tanto, la versión 2 no está ampliamente implementada en Internet. [ cita necesaria ]
Las extensiones se introdujeron en la versión 3. Una CA puede utilizar extensiones para emitir un certificado sólo para un propósito específico (por ejemplo, sólo para firmar objetos digitales ).
En todas las versiones, el número de serie debe ser único para cada certificado emitido por una CA específica (como se menciona en RFC 5280).
RFC 5280 (y sus predecesores) define una serie de extensiones de certificado que indican cómo se debe utilizar el certificado. La mayoría de ellos son arcos del joint-iso-ccitt(2) ds(5) id-ce(29)OID. Algunos de los más comunes, definidos en el apartado 4.2.1, son:
{ id-ce 19 }[ 12] se utilizan para indicar si el certificado es un certificado de CA y puede certificar o emitir otros certificados. Una restricción se puede marcar como crítica. Si una restricción está marcada como crítica, entonces un agente no debe procesar el certificado si no comprende la restricción. Un agente puede continuar procesando una restricción no crítica que no comprende.{ id-ce 15 }[ 13] proporciona un mapa de bits que especifica las operaciones criptográficas que pueden realizarse utilizando la clave pública contenida en el certificado; por ejemplo, podría indicar que la clave debe usarse para firmas pero no para cifrado.{ id-ce 37 }[ 14] se utiliza, normalmente en un certificado hoja, para indicar el propósito de la clave pública contenida en el certificado. Contiene una lista de OID, cada uno de los cuales indica un uso permitido. Por ejemplo, { id-pkix 3 1 }indica que la clave se puede utilizar en el extremo del servidor de una conexión TLS o SSL; { id-pkix 3 4 }indica que la clave se puede utilizar para proteger el correo electrónico.En general, cuando se utiliza RFC 5280, si un certificado tiene varias extensiones que restringen su uso, se deben cumplir todas las restricciones para que un uso determinado sea apropiado. El RFC ofrece el ejemplo específico de un certificado que contiene tanto keyUsage como extendedKeyUsage: en este caso, ambos deben procesarse y el certificado solo puede usarse si ambas extensiones son coherentes al especificar el uso de un certificado. Por ejemplo, NSS usa ambas extensiones para especificar el uso de certificados. [15]
Las autoridades de certificación que operan bajo la PKI de CA/Browser Forum emiten certificados con distintos niveles de validación. Las diferentes validaciones proporcionan diferentes niveles de garantía de que un certificado representa lo que se supone que debe representar. Por ejemplo, un servidor web se puede validar con el nivel más bajo de garantías mediante un correo electrónico llamado Validación de dominio (DV) . O un servidor web se puede validar con un nivel más alto de garantías utilizando métodos más detallados llamados Validación Extendida (EV) .
En la práctica, un certificado DV significa que se emitió un certificado para un dominio, como example.comdespués de que alguien respondió a un correo electrónico enviado a [email protected]. Un certificado EV significa que se emitió un certificado para un dominio como example.com, y una empresa como Ejemplo, LLC es el propietario del dominio, y el propietario fue verificado por los Artículos de Incorporación .
La validación extendida no agrega ningún control de seguridad adicional, por lo que la configuración de un canal seguro usando un certificado EV no es "más sólida" que una configuración de canal usando un nivel diferente de validación como DV.
La validación extendida se indica en un certificado que utiliza la extensión X.509 v3. Cada CA utiliza un Identificador de objeto (OID) diferente para afirmar la validación extendida. No existe un OID único para indicar la validación extendida, lo que complica la programación del agente de usuario. Cada agente de usuario debe tener una lista de OID que indiquen validación extendida.
La PKI de CA/Browser Forum reconoce la validación extendida y muchos navegadores brindan retroalimentación visual al usuario para indicar que un sitio proporciona un certificado EV. Otras PKI, como la PKI de Internet (PKIX), no ponen ningún énfasis especial en la validación extendida. Las herramientas que utilizan políticas PKIX, como cURL y Wget, simplemente tratan un certificado EV como cualquier otro certificado.
El experto en seguridad Peter Gutmann afirma que CA creó certificados de vehículos eléctricos para restaurar los niveles de ganancias después de que la carrera hacia el fondo redujera las ganancias. Durante la carrera hacia el fondo, CA recortó los precios para atraer a los consumidores a comprar sus certificados. Como resultado, las ganancias se redujeron y las CA redujeron el nivel de validación que realizaban hasta el punto de que casi no había garantías en un certificado. [5]
Existen varias extensiones de nombre de archivo de uso común para los certificados X.509. Lamentablemente, algunas de estas extensiones también se utilizan para otros datos, como claves privadas.
.pem– ( Correo electrónico con privacidad mejorada ) Certificado DER codificado en Base64 , encerrado entre y-----BEGIN CERTIFICATE----------END CERTIFICATE-----.cer, .crt, .der– generalmente en formato DER binario , pero los certificados codificados en Base64 también son comunes (ver .pemarriba).p8, .p8e, .pk8– clave privada exportada como se especifica en PKCS#8 . Puede estar en formato DER o PEM y comienza con -----BEGIN PRIVATE KEY-----. La clave cifrada comienza con -----BEGIN ENCRYPTED PRIVATE KEY-----y puede tener la .p8eextensión..p10, .csr– PKCS#10 una Solicitud de firma de certificado (CSR). En formato PEM comienza con -----BEGIN CERTIFICATE REQUEST-----. Estos se generan para enviarlos a las autoridades de certificación (CA). Incluye detalles clave del certificado solicitado, como nombre común (/CN), asunto, organización, estado, país, así como la clave pública del certificado a firmar. Estos son firmados por la CA y se devuelve un certificado. El certificado devuelto es el certificado público (que incluye la clave pública pero no la clave privada), que a su vez puede estar en un par de formatos, pero normalmente en .p7r. [dieciséis].p7r– Respuesta PKCS#7 a la RSC. Contiene el certificado recién firmado y el propio certificado de la CA..p7s- Firma digital PKCS#7 . Puede contener el archivo o mensaje original firmado. Se utiliza en S/MIME para firmar correos electrónicos. Definido en RFC 2311..p7m- Mensaje PKCS#7 (Datos firmados, Datos envueltos), por ejemplo, archivo cifrado ("en sobre"), mensaje o carta de correo electrónico MIME. Definido en RFC 2311..p7c- PKCS#7 degeneró la estructura "solo certificados" de SignedData, sin ningún dato para firmar. Definido en RFC 2311..p7b, .keystore- PKCS#7 Estructura SignedData sin datos, solo paquete de certificados y/o CRL (rara vez), pero no una clave privada. Utiliza el formulario DER o BER o PEM que comienza con -----BEGIN PKCS7-----. El formato utilizado por Windows para el intercambio de certificados. Compatible con Java, pero a menudo tiene .keystoreuna extensión. A diferencia de .pemlos certificados de estilo, este formato tiene una forma definida de incluir certificados de ruta de certificación..p12, .pfx, .pkcs12– PKCS#12 , puede contener certificados (públicos) y claves privadas (protegidas con contraseña) en un solo archivo. El .pfx– Personal Information eXchange PFX, predecesor de PKCS#12 (normalmente contiene datos en formato PKCS#12, por ejemplo, con archivos PFX generados en IIS )..crl- Una Lista de Revocación de Certificados (CRL). Las autoridades certificadoras los producen como una forma de desautorizar los certificados antes de su vencimiento.PKCS#7 es un estándar para firmar o cifrar (oficialmente llamado "envolvente") datos. Dado que el certificado es necesario para verificar los datos firmados, es posible incluirlos en la estructura SignedData.
Una cadena de certificados (consulte el concepto equivalente de "ruta de certificación" definido por RFC 5280 sección 3.2) es una lista de certificados (generalmente comenzando con un certificado de entidad final) seguida de uno o más certificados de CA (generalmente el último es un certificado de entidad propia). -certificado firmado), con las siguientes propiedades:
Las cadenas de certificados se utilizan para comprobar que la clave pública (PK) contenida en un certificado de destino (el primer certificado de la cadena) y otros datos contenidos en él pertenecen efectivamente a su sujeto. Para comprobar esto, la firma en el certificado de destino se verifica utilizando la PK contenida en el siguiente certificado, cuya firma se verifica utilizando el siguiente certificado, y así sucesivamente hasta llegar al último certificado de la cadena. Como el último certificado es un ancla de confianza, alcanzarlo con éxito demostrará que se puede confiar en el certificado de destino.
La descripción en el párrafo anterior es una vista simplificada del proceso de validación de la ruta de certificación según lo definido por RFC 5280 sección 6, que implica comprobaciones adicionales, como verificar las fechas de validez de los certificados, buscar CRL , etc.
Al examinar cómo se construyen y validan las cadenas de certificados, es importante señalar que un certificado concreto puede formar parte de cadenas de certificados muy diferentes (todas ellas válidas). Esto se debe a que se pueden generar varios certificados de CA para el mismo sujeto y clave pública, pero estar firmados con diferentes claves privadas (de diferentes CA o diferentes claves privadas de la misma CA). Por lo tanto, aunque un único certificado X.509 sólo puede tener un emisor y una firma de CA, se puede vincular válidamente a más de un certificado, creando cadenas de certificados completamente diferentes. Esto es crucial para la certificación cruzada entre PKI y otras aplicaciones. [17] Véanse los siguientes ejemplos:
En estos diagramas:
Para gestionar que los certificados de usuario existentes en PKI 2 (como "Usuario 2") sean confiables para PKI 1, CA1 genera un certificado (cert2.1) que contiene la clave pública de CA2. [18] Ahora tanto "cert2 como cert2.1 (en verde) tienen el mismo asunto y clave pública, por lo que hay dos cadenas válidas para cert2.2 (Usuario 2): "cert2.2 → cert2" y "cert2.2 → cert2.1 → cert1".
De manera similar, CA2 puede generar un certificado (cert1.1) que contenga la clave pública de CA1 para que PKI 2 confíe en los certificados de usuario existentes en PKI 1 (como "Usuario 1").
Comprensión de la construcción de la ruta de certificación (PDF) . Foro PKI. Septiembre de 2002. Para permitir una transición elegante del antiguo par de claves de firma al nuevo par de claves de firma, la CA debe emitir un certificado que contenga la antigua clave pública firmada por la nueva clave de firma privada y un certificado que contenga la nueva clave pública firmada. por la antigua clave de firma privada. Ambos certificados son autoexpedidos, pero ninguno está autofirmado . Tenga en cuenta que estos son adicionales a los dos certificados autofirmados (uno antiguo y otro nuevo).
Dado que tanto cert1 como cert3 contienen la misma clave pública (la anterior), existen dos cadenas de certificados válidas para cert5: "cert5 → cert1" y "cert5 → cert3 → cert2", y de manera análoga para cert6. Esto permite que una parte que tenga el nuevo certificado de CA raíz o el antiguo como ancla de confianza pueda confiar indiferentemente en los certificados de usuario antiguos (como cert5) y en los nuevos (como cert6) durante la transición a las nuevas claves de CA. [19]
Este es un ejemplo de un certificado X.509 decodificado que fue utilizado en el pasado por wikipedia.org y varios otros sitios web de Wikipedia. Fue emitido por GlobalSign , como se indica en el campo Emisor. Su campo Asunto describe Wikipedia como una organización, y su campo Nombre alternativo del sujeto (SAN) para DNS describe los nombres de host para los que podría usarse. El campo Información de clave pública del sujeto contiene una clave pública ECDSA , mientras que la firma en la parte inferior fue generada por la clave privada RSA de GlobalSign . (Las firmas en estos ejemplos están truncadas).
Certificado: Datos: Versión: 3 (0x2) Número de serie: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Algoritmo de firma: sha256WithRSAEncryption Emisor: C=BE, O=GlobalSign nv-sa, CN=Validación de organización GlobalSign CA - SHA256 - G2 Validez No antes: 21 de noviembre 08:00:00 2016 GMT No después: 22 de noviembre 07:59:59 2017 GMT Asunto: C=EE.UU., ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Información de clave pública del sujeto: Algoritmo de clave pública: id-ecPublicKey Clave pública: (256 bits) pub: 00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9d:3b:ef OID ASN1: prime256v1 CURVA NIST: P-256 Extensiones X509v3: Uso de clave X509v3: crítico Firma digital, acuerdo clave Acceso a la información de la autoridad: Emisores de CA - URI: http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2 Políticas de certificado X509v3: Política: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Política: 2.23.140.1.2.2 Restricciones básicas de X509v3: CA:FALSO Puntos de distribución de CRL X509v3: Nombre completo: URI: http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl Nombre alternativo del sujeto X509v3: DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS: *.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS: *.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*. wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource. org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS: wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org Uso de clave extendida X509v3: Autenticación de servidor web TLS, Autenticación de cliente web TLS Identificador de clave de asunto X509v3: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 Identificador de clave de autoridad X509v3: ID de clave:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
Algoritmo de firma: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35: ...
Para validar este certificado de entidad final, se necesita un certificado intermedio que coincida con su identificador de clave de emisor y autoridad:
En una conexión TLS, un servidor configurado correctamente proporcionaría el intermediario como parte del protocolo de enlace. Sin embargo, también es posible recuperar el certificado intermedio obteniendo la URL "Emisores de CA" del certificado de entidad final.
Este es un ejemplo de un certificado intermedio que pertenece a una autoridad certificadora . Este certificado firmó el certificado de entidad final anterior y fue firmado por el certificado raíz a continuación. Tenga en cuenta que el campo de asunto de este certificado intermedio coincide con el campo de emisor del certificado de entidad final que firmó. Además, el campo "identificador de clave de sujeto" en el intermedio coincide con el campo "identificador de clave de autoridad" en el certificado de entidad final.
Certificado: Datos: Versión: 3 (0x2) Número de serie: 04:00:00:00:00:01:44:4e:f0:42:47 Algoritmo de firma: sha256WithRSAEncryption Emisor: C=BE, O=GlobalSign nv-sa, OU=CA raíz, CN=CA raíz de GlobalSign Validez No antes: 20 de febrero a las 10:00:00 2014 GMT No después: 20 de febrero a las 10:00:00 2024 GMT Asunto: C=BE, O=GlobalSign nv-sa, CN=Validación de organización GlobalSign CA - SHA256 - G2 Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bits) Módulo: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de clave X509v3: crítico Signo de certificado, signo CRL Restricciones básicas de X509v3: críticas CA: VERDADERO, ruta: 0 Identificador de clave de asunto X509v3: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Políticas de certificado X509v3: Política: X509v3 Cualquier política CPS: https://www.globalsign.com/repository/ Puntos de distribución de CRL X509v3: Nombre completo: URI: http://crl.globalsign.net/root.crl Acceso a la información de la autoridad: OCSP-URI:http://ocsp.globalsign.com/rootr1 Identificador de clave de autoridad X509v3: ID de clave:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Algoritmo de firma: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ...
Este es un ejemplo de un certificado raíz autofirmado que representa una autoridad certificadora . Sus campos emisor y asunto son los mismos y su firma se puede validar con su propia clave pública. La validación de la cadena de confianza tiene que terminar aquí. Si el programa de validación tiene este certificado raíz en su almacén de confianza, el certificado de entidad final puede considerarse confiable para su uso en una conexión TLS. De lo contrario, el certificado de entidad final se considera no confiable.
Certificado: [20] Datos: Versión: 3 (0x2) Número de serie: 04:00:00:00:00:01:15:4b:5a:c3:94 Algoritmo de firma: sha1WithRSAEncryption Emisor: C=BE, O=GlobalSign nv-sa, OU=CA raíz, CN=CA raíz de GlobalSign Validez No antes: 1 de septiembre a las 12:00:00 1998 GMT No después: 28 de enero a las 12:00:00 2028 GMT Asunto: C=BE, O=GlobalSign nv-sa, OU=CA raíz, CN=CA raíz de GlobalSign Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bits) Módulo: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de clave X509v3: crítico Signo de certificado, signo CRL Restricciones básicas de X509v3: críticas CA: VERDADERO Identificador de clave de asunto X509v3: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Algoritmo de firma: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...
Hay varias publicaciones sobre problemas de PKI de Bruce Schneier , Peter Gutmann y otros expertos en seguridad. [21] [22] [23]
Las implementaciones adolecen de fallas de diseño, errores, diferentes interpretaciones de los estándares y falta de interoperabilidad de los diferentes estándares. Algunos problemas son:
Los sistemas de firma digital dependen de funciones hash criptográficas seguras para funcionar. Cuando una infraestructura de clave pública permite el uso de una función hash que ya no es segura, un atacante puede explotar las debilidades de la función hash para falsificar certificados. Específicamente, si un atacante puede producir una colisión de hash , puede convencer a una CA para que firme un certificado con contenidos inofensivos, donde el hash de esos contenidos es idéntico al hash de otro conjunto malicioso de contenidos de certificados, creado por el atacante. con valores de su elección. Luego, el atacante puede agregar la firma proporcionada por la CA al contenido de su certificado malicioso, lo que da como resultado un certificado malicioso que parece estar firmado por la CA. Debido a que el contenido del certificado malicioso lo elige únicamente el atacante, pueden tener fechas de validez o nombres de host diferentes a los del certificado inofensivo. El certificado malicioso puede incluso contener un campo "CA: true" que le permita emitir más certificados confiables.
Explotar una colisión de hash para falsificar firmas X.509 requiere que el atacante pueda predecir los datos que firmará la autoridad certificadora. Esto puede mitigarse en cierta medida si la CA genera un componente aleatorio en los certificados que firma, normalmente el número de serie. El CA/Browser Forum exige la entropía del número de serie en su Sección 7.1 de Requisitos básicos desde 2011. [39]
A partir del 1 de enero de 2016 [actualizar], los requisitos básicos prohíben la emisión de certificados utilizando SHA-1. A principios de 2017 [actualizar], Chrome [40] y Firefox [41] rechazan los certificados que utilizan SHA-1. En mayo de 2017, [actualizar]tanto Edge [42] como Safari [43] también rechazan el certificado SHA-1. Los validadores X.509 que no son de navegador aún no rechazan los certificados SHA-1. [44]
En 1995, el Grupo de Trabajo de Ingeniería de Internet junto con el Instituto Nacional de Estándares y Tecnología [50] formaron el grupo de trabajo de Infraestructura de clave pública (X.509). El grupo de trabajo, concluido en junio de 2014, [51] se conoce comúnmente como "PKIX". Produjo RFC y otra documentación estándar sobre el uso y la implementación de X.509 en la práctica. En particular, produjo el RFC 3280 y su sucesor, el RFC 5280, que definen cómo utilizar X.509 en los protocolos de Internet.
TLS/SSL y HTTPS utilizan el perfil RFC 5280 de X.509, al igual que S/MIME (Extensiones seguras de correo de Internet multipropósito) y el método EAP-TLS para la autenticación WiFi. Cualquier protocolo que utilice TLS, como SMTP, POP, IMAP, LDAP, XMPP y muchos más, utiliza inherentemente X.509.
IPsec puede utilizar el perfil RFC 4945 para autenticar pares.
La especificación de seguridad de OpenCable define su propio perfil de X.509 para su uso en la industria del cable.
Los dispositivos como las tarjetas inteligentes y los TPM suelen llevar certificados para identificarse a sí mismos o a sus propietarios. Estos certificados están en formato X.509.
El estándar WS-Security define la autenticación mediante TLS o mediante su propio perfil de certificado. [20] Ambos métodos utilizan X.509.
El sistema de firma de código Microsoft Authenticode utiliza X.509 para identificar a los autores de programas informáticos.
El estándar de comunicación de automatización industrial OPC UA utiliza X.509.
SSH generalmente utiliza un modelo de seguridad Trust On First Use y no necesita certificados. Sin embargo, la popular implementación OpenSSH admite un modelo de identidad firmado por una CA basado en su propio formato de certificado no X.509. [52]
A continuación se muestra una vista simplificada del modelo arquitectónico asumido por la Infraestructura de Clave Pública utilizando las especificaciones X.509 (PKIX).
{{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite web}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace ) Este artículo incorpora texto de esta fuente, que está disponible bajo la licencia CC BY-SA 2.5.