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 las 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 de certificación o es autofirmado. Cuando un certificado está firmado por una autoridad de certificación de confianza o validado por otros medios, alguien que posea ese certificado puede usar la clave pública que contiene para establecer comunicaciones seguras con otra parte o validar documentos firmados digitalmente por 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 han sido considerados inválidos por una autoridad firmante, así como un algoritmo de validación de ruta de certificación , que permite que los certificados sean firmados por certificados de CA intermedios, que, a su vez, son firmados por otros certificados, llegando eventualmente a un ancla de confianza .
X.509 está definido por el "Sector de Normalización" de la UIT ( SG17 de la UIT-T ), en el Grupo de Estudio 17 de la UIT-T, y se basa en la Notación de Sintaxis Abstracta Uno (ASN.1), otra norma de la UIT-T.
El estándar X.509 se publicó inicialmente el 3 de julio de 1988 y comenzó a usarse en asociación con el estándar X.500 . Sus primeras tareas fueron proporcionar a los usuarios un acceso seguro a los recursos de información y evitar un ataque criptográfico de intermediario . Supone un sistema jerárquico estricto de autoridades de certificación (CA) para emitir los certificados. Esto contrasta con los modelos de red de confianza , como PGP , donde cualquiera (no solo CA especiales) puede firmar y, por lo tanto, dar fe de la validez de los certificados clave de otros.
La versión 3 de X.509 incluye la flexibilidad para soportar otras topologías como puentes y mallas . [2] Puede usarse en una red de confianza de igual a igual, similar a OpenPGP , [ cita requerida ] pero rara vez se usó de esa manera a partir de 2004. [actualizar]El sistema X.500 solo 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]
Un problema inicial 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 X.500 global 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 podían 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]
Aunque PKIX hace referencia al estándar PKI de la IETF o de Internet, existen muchas otras PKI con políticas diferentes. Por ejemplo, el gobierno de los EE. UU. tiene su propia PKI con sus propias políticas, y el CA/Browser Forum tiene su propia PKI con sus propias políticas. La PKI del gobierno de los EE. UU. es un libro enorme de más de 2500 páginas. Si la PKI de una organización difiere demasiado de la del IETF o del CA/Browser Forum, la organización corre el riesgo de perder la interoperabilidad con herramientas comunes como los navegadores web , cURL y Wget . Por ejemplo, si una PKI tiene una política de solo emitir certificados los lunes, las herramientas comunes como cURL y Wget no harán cumplir la política y permitirán la emisión de un certificado un martes. [5]
Los certificados X.509 vinculan una identidad a una clave pública mediante una firma digital. En el sistema X.509, hay 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 intermedios o subordinados. Un certificado de entidad final identifica al usuario, como una persona, una organización o una empresa. Un certificado de entidad final no puede emitir otros certificados. Un certificado de entidad final a veces se denomina certificado de hoja, ya que no se pueden emitir otros certificados por debajo de él.
Una organización que desea un certificado firmado lo solicita a una CA mediante 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 en secreto la clave privada y la utiliza para firmar la CSR. La CSR contiene información que identifica al solicitante y la clave pública del solicitante que se utiliza para verificar la firma de la CSR, y el nombre distintivo (DN) que es exclusivo de la persona, organización o empresa. La CSR puede ir acompañada de otras credenciales o pruebas de identidad requeridas por la autoridad de certificación.
La CSR se validará mediante una autoridad de registro (RA) y, a continuación, la autoridad de certificación emitirá un certificado que vinculará una clave pública a un nombre distintivo en particular . Las funciones de autoridad de registro y autoridad de certificación suelen ser unidades de negocio independientes con funciones separadas para reducir el riesgo de fraude.
Los certificados raíz de confianza de una organización se pueden distribuir a todos los empleados para que puedan utilizar el sistema PKI de la empresa. Los 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 de certificación funcionarán instantáneamente; en efecto, 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 la implementación de listas de revocación de certificados (CRL). Otra forma aprobada por la IETF de comprobar la validez de un certificado es el Protocolo de estado de certificados en línea (OCSP). Firefox 3.0 habilitaba la comprobación de OCSP de forma predeterminada, al igual que las versiones de Windows , al menos desde Vista y posteriores. [9]
La estructura prevista por los estándares se expresa en un lenguaje formal, Abstract Syntax Notation One (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] : §4.1.2.9: Extensiones Cada extensión tiene su propio identificador ú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 certificados 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. [10] : §4.2: Extensiones de certificados
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.
La UIT-T introdujo identificadores únicos de emisor y de sujeto en la versión 2 para permitir la reutilización del nombre del emisor o del sujeto después de un tiempo. Un ejemplo de reutilización será cuando una CA se declare en quiebra y su nombre se elimine de la lista pública del país. Después de un tiempo, otra CA con el mismo nombre puede registrarse, aunque no esté relacionada con la primera. Sin embargo, la IETF recomienda que no se reutilicen los nombres de emisor y de sujeto. Por lo tanto, la versión 2 no se ha implementado ampliamente en Internet. [ cita requerida ]
Las extensiones se introdujeron en la versión 3. Una CA puede usar extensiones para emitir un certificado solo para un propósito específico (por ejemplo, solo 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 ellas son arcos del joint-iso-ccitt(2) ds(5) id-ce(29)OID. Algunas de las más comunes, definidas en la sección 4.2.1, son:
{ id-ce 19 }, [10] : §4.2.1.9 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 se marca como crítica, entonces un agente debe dejar de procesar el certificado si el agente no comprende la restricción. Un agente puede continuar procesando una restricción no crítica que no comprende.{ id-ce 15 }, [10] : §4.2.1.3 proporciona un mapa de bits que especifica las operaciones criptográficas que se pueden realizar 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 }, [10] : §4.2.1.12 se utiliza, normalmente en un certificado de 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. La RFC ofrece el ejemplo específico de un certificado que contiene keyUsage y extendedKeyUsage: en este caso, se deben procesar ambas y el certificado solo se puede utilizar si ambas extensiones son coherentes al especificar el uso de un certificado. Por ejemplo, NSS utiliza ambas extensiones para especificar el uso del certificado. [11]
Las autoridades de certificación que operan bajo la PKI del CA/Browser Forum emiten certificados con distintos niveles de validación. Las diferentes validaciones proporcionan distintos niveles de garantía de que un certificado representa lo que se supone que debe representar. Por ejemplo, un servidor web puede validarse en el nivel más bajo de garantías utilizando un correo electrónico llamado Validación de dominio (DV) . O un servidor web puede validarse en 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 Example, LLC es la propietaria 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 que utiliza un certificado EV no es "más fuerte" que una configuración de canal que utiliza un nivel diferente de validación como DV.
La validación extendida se indica en un certificado mediante la extensión X.509 v3. Cada CA utiliza un identificador de objeto (OID) diferente para confirmar la validación extendida. No existe un único OID que indique 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 la validación extendida.
La PKI del CA/Browser Forum reconoce la validación extendida y muchos navegadores proporcionan una respuesta visual al usuario para indicar que un sitio proporciona un certificado EV. Otras PKI, como la PKI de Internet (PKIX), no hacen 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 las CA crearon certificados EV para restablecer los niveles de ganancias después de que la carrera hacia el abismo redujera las ganancias. Durante la carrera hacia el abismo, las CA redujeron los precios para atraer a los consumidores a comprar sus certificados. Como resultado, las ganancias se redujeron y las CA disminuyeron 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. Algunas de estas extensiones también se utilizan para otros datos, como las claves privadas.
.pem– ( Correo electrónico con privacidad mejorada ) Certificado DER codificado en Base64 , adjunto 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 que 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-----. Se generan para su envío a las autoridades de certificación (CA). Incluye detalles clave del certificado solicitado, como el nombre común (/CN), el sujeto, la organización, el estado, el país, así como la clave pública del certificado que se va 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 puede estar en un par de formatos, pero normalmente en .p7r. [12].p7r– Respuesta PKCS#7 a la CSR. Contiene el certificado recién firmado y el certificado propio de la CA..p7s– Firma digital PKCS#7 . Puede contener el archivo o mensaje original firmado. Se utiliza en S/MIME para la firma de correo electrónico. Se define en RFC 2311..p7m– PKCS#7 (SignedData, EnvelopedData) Mensaje, por ejemplo, archivo cifrado ("envuelto"), mensaje o carta de correo electrónico MIME. Definido en RFC 2311..p7c– PKCS#7 degeneró la estructura SignedData "solo para certificados", sin ningún dato para firmar. Definido en RFC 2311..p7b, .keystore– Estructura PKCS#7 SignedData sin datos, solo un paquete de certificados y/o CRL (raramente), pero no una clave privada. Utiliza el formato DER o BER o PEM que comienza con -----BEGIN PKCS7-----. El formato que utiliza Windows para el intercambio de certificados. Compatible con Java, pero a menudo se incluye .keystorecomo 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. .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 de certificación las elaboran como una forma de desautorizar certificados antes de su vencimiento.PKCS#7 es un estándar para firmar o cifrar (oficialmente llamado "enveloping") 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 en la sección 3.2 del RFC 5280) es una lista de certificados (que generalmente comienza con un certificado de entidad final) seguido de uno o más certificados de CA (generalmente el último es un certificado autofirmado), 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 titular. Para comprobarlo, la firma del 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 del párrafo anterior es una vista simplificada del proceso de validación de la ruta de certificación según se define en la sección 6 del RFC 5280, que implica verificaciones 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 tener en cuenta 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 claves privadas diferentes (de diferentes CA o claves privadas diferentes de la misma CA). Por lo tanto, aunque un único certificado X.509 puede tener solo un emisor y una firma de CA, se puede vincular de forma válida a más de un certificado, lo que genera cadenas de certificados completamente diferentes. Esto es crucial para la certificación cruzada entre PKI y otras aplicaciones. [13] 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. [14] Ahora tanto "cert2 como cert2.1 (en verde) tienen el mismo sujeto 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 los certificados de usuario existentes en PKI 1 (como "Usuario 1") sean confiables para PKI 2.
Comprensión de la construcción de rutas de certificación (PDF) . Foro PKI. Septiembre de 2002. Para permitir una transición sin problemas del par de claves de firma anterior al nuevo par de claves de firma, la CA debe emitir un certificado que contenga la clave pública anterior firmada por la nueva clave de firma privada y un certificado que contenga la nueva clave pública firmada por la clave de firma privada anterior. Ambos certificados son autoemitidos, pero ninguno es autofirmado . Tenga en cuenta que estos son adicionales a los dos certificados autofirmados (uno anterior y uno nuevo).
Dado que tanto cert1 como cert3 contienen la misma clave pública (la antigua), existen dos cadenas de certificados válidas para cert5: "cert5 → cert1" y "cert5 → cert3 → cert2", y análogamente para cert6. Esto permite que los certificados de usuario antiguos (como cert5) y los nuevos (como cert6) puedan ser confiables indistintamente por una parte que tenga el nuevo certificado de CA raíz o el antiguo como ancla de confianza durante la transición a las nuevas claves de CA. [15]
Este es un ejemplo de un certificado X.509 decodificado que fue utilizado en el pasado por wikipedia.org y otros sitios web de Wikipedia. Fue emitido por GlobalSign , como se indica en el campo Emisor. Su campo Asunto describe a 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=GlobalSign Organización Validación CA - SHA256 - G2 Validez No antes: 21 de noviembre de 2016, 08:00:00 GMT No después de: 22 de noviembre de 2017, 07:59:59 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 bit) 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 Identificador de origen ASN1: prime256v1 CURVA NIST: P-256 Extensiones X509v3: Uso de la clave X509v3: crítico Firma digital, acuerdo de 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 certificación X509v3: Política: 1.3.6.1.4.1.4146.1.20 Página de inicio: 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: Dirección URL: http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Nombre alternativo del sujeto: 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 extendido de la clave X509v3: Autenticación de servidor web TLS, autenticación de cliente web TLS Identificador de clave de sujeto 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 emisor y su identificador de clave de autoridad:
En una conexión TLS, un servidor configurado correctamente proporcionaría el certificado intermedio como parte del protocolo de enlace. Sin embargo, también es posible recuperar el certificado intermedio obteniendo la URL de "Emisores de CA" del certificado de la entidad final.
Este es un ejemplo de un certificado intermedio que pertenece a una autoridad de certificación . Este certificado firmó el certificado de entidad final anterior y fue firmado por el certificado raíz siguiente. 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 de 2014, 10:00:00 GMT No después de: 20 de febrero de 2024, 10:00:00 GMT Asunto: C=BE, O=GlobalSign nv-sa, CN=GlobalSign CA de validación de organización - SHA256 - G2 Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bit) Módulo: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de la clave X509v3: crítico Letrero de certificado, letrero CRL Restricciones básicas de X509v3: críticas CA:TRUE, longitud de ruta:0 Identificador de clave de sujeto X509v3: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Políticas de certificación X509v3: Política: X509v3 Cualquier política Página de inicio: https://www.globalsign.com/repository/ Puntos de distribución de CRL X509v3: Nombre completo: Dirección URL: 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 de certificación . Sus campos de emisor y sujeto son los mismos, y su firma se puede validar con su propia clave pública. La validación de la cadena de confianza debe terminar aquí. Si el programa de validación tiene este certificado raíz en su almacén de confianza, el certificado de entidad final se puede considerar confiable para su uso en una conexión TLS. De lo contrario, el certificado de entidad final se considera no confiable.
Certificado: [16] 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 12:00:00 1998 GMT No después del 28 de enero de 2028, 12:00:00 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 bit) Módulo: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de la clave X509v3: crítico Letrero de certificado, letrero CRL Restricciones básicas de X509v3: críticas CA:VERDADERO Identificador de clave de sujeto 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 los problemas de PKI realizadas por Bruce Schneier , Peter Gutmann y otros expertos en seguridad. [17] [18] [19]
Las implementaciones sufren fallas de diseño, errores, diferentes interpretaciones de estándares y falta de interoperabilidad entre 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. En concreto, si un atacante es capaz de producir una colisión de hash , puede convencer a una CA de que firme un certificado con contenido inocuo, donde el hash de ese contenido es idéntico al hash de otro conjunto malicioso de contenidos de certificado, creado por el atacante con valores de su elección. El atacante puede entonces añadir 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 es elegido únicamente por el atacante, puede tener fechas de validez o nombres de host diferentes a los del certificado inocuo. El certificado malicioso puede incluso contener un campo "CA: true" que le permite emitir más certificados de confianza.
Para aprovechar una colisión de hash con el fin de falsificar firmas X.509, el atacante debe ser capaz de predecir los datos que firmará la autoridad de certificación. Esto se puede mitigar en cierta medida si la autoridad de certificación 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. [35]
A partir del 1 de enero de 2016 [actualizar], los requisitos básicos prohíben la emisión de certificados que utilicen SHA-1. A principios de 2017 [actualizar], Chrome [36] y Firefox [37] rechazan los certificados que utilizan SHA-1. A partir de mayo de 2017, [actualizar]tanto Edge [38] como Safari [39] también rechazan los certificados SHA-1. Los validadores X.509 que no son de navegador todavía no rechazan los certificados SHA-1. [40]
En 1995, el Grupo de Trabajo de Ingeniería de Internet , en colaboración con el Instituto Nacional de Estándares y Tecnología [45], formó el grupo de trabajo de Infraestructura de Clave Pública (X.509). El grupo de trabajo, que concluyó sus actividades en junio de 2014, [46] se conoce comúnmente como "PKIX". Produjo RFC y otra documentación de estándares sobre el uso y la implementación de X.509 en la práctica. En particular, produjo RFC 3280 y su sucesor 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 (Secure Multipurpose Internet Mail Extensions) 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 módulos de protección de terminales 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 a través de TLS o a través de su propio perfil de certificado. [16] 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 de confianza al primer uso y no necesita certificados. Sin embargo, la popular implementación de OpenSSH sí admite un modelo de identidad firmado por una CA basado en su propio formato de certificado distinto de X.509. [47]
A continuación se presenta una vista simplificada del modelo arquitectónico asumido por las especificaciones de infraestructura de clave pública que utilizan X.509 (PKIX).
{{cite web}}: CS1 maint: 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.