Hispanopedia Wiki
Articulo de referencia

X.509

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

Hispanopedia WikiContenido en espanolLectura gratuita

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

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 (CA) o es autofirmado. Cuando un certificado está firmado por una autoridad de certificación de confianza o validado por otros medios, quien lo posee puede usar 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 certificados que han sido considerados inválidos por una autoridad de firma, 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, hasta llegar finalmente a un ancla de confianza .

La norma X.509 está definida 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.

Historia y uso

El estándar X.509 se publicó inicialmente el 3 de julio de 1988 y se desarrolló en conjunto con el estándar X.500 . Sus primeras tareas consistieron en proporcionar a los usuarios acceso seguro a los recursos de información y evitar ataques de intermediario criptográficos . Se basa en un sistema jerárquico estricto de autoridades de certificación (CA) para la emisión de certificados. Esto contrasta con los modelos de red de confianza , como PGP , donde cualquier persona (no solo las CA especializadas) puede firmar y, por lo tanto, certificar 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 utilizarse en una red de confianza punto a punto, similar a OpenPGP , pero rara vez se utilizaba de esa manera en 2004.El sistema X.500 solo ha sido implementado por naciones soberanas para cumplir con los tratados 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, tal como se especifica en RFC 5280 , comúnmente llamado PKIX para Infraestructura de Clave Pública (X.509) . [ 3 ] 

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 radica en que el cliente no sabe dónde obtener los certificados intermedios que faltan porque el directorio global X.500 nunca se materializó. Este problema se mitigó incluyendo todos los certificados intermedios en la solicitud. Por ejemplo, los primeros servidores web solo enviaban el certificado del servidor al cliente. Los clientes que carecían de un certificado de CA intermedio o no sabían dónde encontrarlo no podían establecer una ruta válida desde la CA hasta el certificado del servidor. Para solucionar este problema, ahora los servidores web envían todos los certificados intermedios junto con el certificado del servidor. [ 4 ]

Si bien PKIX se refiere al estándar PKI de la 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 el CA/Browser Forum también tiene la suya. La PKI del Gobierno de EE. UU. es un extenso documento de más de 2500 páginas. Si la PKI de una organización difiere demasiado de la de la IETF o del CA/Browser Forum, corre el riesgo de perder la interoperabilidad con herramientas comunes como navegadores web , cURL y Wget . Por ejemplo, si una PKI tiene la política de emitir certificados solo los lunes, herramientas comunes como cURL y Wget no aplicarán dicha política y permitirán la emisión de un certificado un martes. [ 4 ]

Certificados

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: un certificado de CA y un certificado de entidad final. Un certificado de CA puede emitir otros certificados. El certificado de CA autofirmado de nivel superior se denomina a veces certificado raíz de CA. Otros certificados de CA se denominan certificados de CA intermedios o subordinados. 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. A veces se le denomina certificado 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 la Solicitud de Firma de Certificado (CSR) , el Protocolo Simple de Inscripción de Certificados (SCEP) o el Protocolo de Gestión de Certificados (CMP) . La organización primero genera un par de claves , manteniendo la clave privada en secreto y utilizándola para firmar la CSR. La CSR contiene información que identifica al solicitante y su clave pública , que se utiliza para verificar la firma, así como el Nombre Distinguido (DN), único para la persona, organización o empresa. La CSR puede ir acompañada de otras credenciales o pruebas de identidad requeridas por la autoridad certificadora.

La solicitud de firma de certificado (CSR) se validará mediante una autoridad de registro (RA), y posteriormente la autoridad de certificación emitirá un certificado que vincula una clave pública a un nombre distinguido específico . Las funciones de autoridad de registro y autoridad de certificación suelen ser unidades de negocio independientes, sujetas a una separación de funciones para reducir el riesgo de fraude.

Los certificados raíz de confianza de una organización pueden distribuirse a todos los empleados para que puedan usar 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 de certificación funcionarán de inmediato; 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 o HTML que contiene una lista de las CA incluidas. [ 7 ]

X.509 y RFC 5280 también incluyen estándares para implementaciones de listas de revocación de certificados (CRL). Otra forma aprobada por la IETF de verificar la validez de un certificado es el Protocolo de estado de certificado en línea (OCSP). Firefox 3.0 habilitó la verificación OCSP de forma predeterminada, al igual que las versiones de Windows a partir de Vista . [ 8 ] 

Estructura de un certificado

La estructura prevista por las normas 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:

  • Certificado
    • Número de versión
    • Número de serie
    • ID del algoritmo de firma
    • Nombre del emisor
    • Período de validez
      • No antes
      • No después
    • Nombre del sujeto
    • Información de clave pública del sujeto
      • Algoritmo de clave pública
      • Clave pública del sujeto
    • Identificador único del emisor (opcional)
    • Identificador único del sujeto (opcional)
    • Extensiones (opcionales)
      • ...
  • Algoritmo de firma de certificado
  • Firma del certificado

El campo Extensiones, si está presente, es una secuencia de una o más extensiones de certificado. [ 9 ] : §4.1.2.9: Extensiones 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 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. [ 9 ] : §4.2: Extensiones de certificado

La estructura de la versión 1 se describe en el RFC 1422 . 

El formato interno de los identificadores únicos del emisor y del sujeto especificados en X.520 El Directorio: Recomendación de tipos de atributos seleccionados.

La UIT-T introdujo identificadores únicos de emisor y sujeto en la versión 2 para permitir la reutilización del nombre del emisor o sujeto después de un tiempo. Un ejemplo de reutilización sería cuando una CA quiebra y su nombre se elimina de la lista pública del país. Después de un tiempo, otra CA con el mismo nombre podría registrarse, aunque no tenga relación con la primera. Sin embargo, el IETF recomienda que no se reutilicen los nombres de emisor y sujeto. Por lo tanto, la versión 2 no está ampliamente implementada en Internet.

Las extensiones se introdujeron en la versión 3. Una CA puede utilizar 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 ). 

Extensiones que informan sobre un uso específico de un certificado.

RFC 5280 (y sus predecesores) define una serie de extensiones de certificado que indican cómo debe utilizarse el certificado. La mayoría de ellas son arcos del OID. Algunas de las más comunes, definidas en la sección 4.2.1, son: joint-iso-ccitt(2) ds(5) id-ce(29)

  • Restricciones básicas, { id-ce 19 }[ 9 ] : §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 puede marcarse como crítica. Si una restricción se marca como crítica, el agente no podrá procesar el certificado si no la comprende. El agente puede continuar procesando una restricción no crítica que no comprenda.
  • Uso de claves, { id-ce 15 }, [ 9 ] : §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.
  • Uso extendido de clave, { id-ce 37 }, [ 9 ] : §4.2.1.12 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 puede utilizarse en el extremo del servidor de una conexión TLS o SSL; { id-pkix 3 4 }indica que la clave puede utilizarse para proteger el correo electrónico.

En general, al utilizar RFC 5280 , si un certificado tiene varias extensiones que restringen su uso, todas las restricciones deben cumplirse para que un uso determinado sea apropiado. El RFC proporciona el ejemplo específico de un certificado que contiene tanto keyUsage como extendedKeyUsage: en este caso, ambas deben procesarse y el certificado solo puede utilizarse si ambas extensiones son coherentes al especificar el uso del certificado. Por ejemplo, NSS utiliza ambas extensiones para especificar el uso del certificado. [ 10 ] 

Certificados de validación extendida

Las autoridades de certificación que operan bajo la infraestructura de clave pública (PKI) del Foro CA/Browser emiten certificados con distintos niveles de validación. Estos niveles de validación ofrecen diferentes garantías de que un certificado representa lo que se supone que debe representar. Por ejemplo, un servidor web puede validarse con el nivel de garantía más bajo mediante un correo electrónico denominado Validación de Dominio (DV) . O bien, puede validarse con un nivel de garantía superior mediante métodos más detallados denominados 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 se afirmó el control sobre ese dominio, por ejemplo, respondiendo a un correo electrónico enviado a webmaster@example.com. 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 la propietaria fue verificada por los Estatutos de Incorporación .

La validación extendida no añade ningún control de seguridad adicional , por lo que la configuración del canal seguro mediante un certificado EV no es "más robusta" que una configuración de canal que utilice un nivel de validación diferente, 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 afirmar 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. Otras PKI, como la PKI de Internet (PKIX), no hacen especial hincapié en la validación extendida. Las herramientas que utilizan las políticas de PKIX, como cURL y Wget, simplemente tratan un certificado EV como cualquier otro certificado. Hasta 2019, muchos navegadores solían proporcionar una clara indicación visual en la barra de URL para indicar al usuario que un sitio proporcionaba un certificado EV. Tras estudios e informes que demostraron la ineficacia de los certificados EV y su utilidad para los delincuentes a la hora de inyectar elementos engañosos en la parte central de la interfaz de usuario del navegador, todos los navegadores principales eliminaron su anterior indicación visual prominente de la barra de URL. [ 11 ] [ 12 ] [ 13 ] En su lugar, desde 2019, navegadores como Chromium y Firefox ocultan la información de emisión del EV en submenús, donde se muestra de forma neutral, sin resaltar ni mencionar la validación extendida.

El experto en seguridad Peter Gutmann afirma que las CA crearon certificados EV para recuperar sus niveles de ganancias después de que la carrera hacia la baja redujera sus beneficios. Durante esta carrera, las CA redujeron los precios para atraer a los consumidores a comprar sus certificados. Como resultado, las ganancias disminuyeron y las CA bajaron el nivel de validación que realizaban hasta el punto de que prácticamente no existían garantías sobre un certificado. [ 4 ]

extensiones de nombre de archivo de certificado

Existen varias extensiones de archivo de uso común para los certificados X.509. 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 , incluido entre y-----BEGIN CERTIFICATE----------END CERTIFICATE-----
  • .cer, .crt, .der– normalmente en formato binario DER , pero los certificados codificados en Base64 también son comunes (ver .pemmás arriba)
  • .p8, .p8e, .pk8– clave privada exportada según lo especificado 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-----. Estas 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. Estas son firmadas 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 generalmente en .p7r. [ 14 ]
  • .p7r– Respuesta PKCS#7 a la CSR. Contiene el certificado recién firmado y el certificado de la propia CA.
  • .p7sFirma digital PKCS #7 . Puede contener el archivo o mensaje original firmado. Se utiliza en S/MIME para la firma de correo electrónico. Definida en la RFC 2311.
  • .p7m– Mensaje PKCS#7 (SignedData, EnvelopedData), por ejemplo, archivo cifrado ("enveloped"), mensaje o correo electrónico MIME. Definido en RFC 2311.
  • .p7c– Estructura SignedData degenerada de PKCS#7 "solo certificados", sin datos para firmar. Definida en RFC 2311.
  • .p7b, .keystore– Estructura PKCS#7 SignedData sin datos, solo paquete de certificado(s) y/o CRL (rara vez) pero no una clave privada. Utiliza el formato 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 .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 (generalmente 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 generan para desautorizar certificados antes de su vencimiento.

PKCS#7 es un estándar para firmar o cifrar (oficialmente llamado "encapsulación") datos. Dado que el certificado es necesario para verificar los datos firmados, es posible incluirlo en la estructura SignedData.

Cadenas de certificados y certificación cruzada

Una cadena de certificados (también conocida como "ruta de certificación" [ 9 ] : §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 autofirmado), con las siguientes propiedades:

  1. El emisor de cada certificado (excepto el último) coincide con el sujeto del siguiente certificado de la lista.
  2. Cada certificado (excepto el último) está firmado con la clave secreta correspondiente al siguiente certificado de la cadena (es decir, la firma de un certificado se puede verificar utilizando la clave pública contenida en el certificado siguiente).
  3. El último certificado de la lista es un ancla de confianza : un certificado en el que confías porque te fue entregado mediante un procedimiento fiable.

Las cadenas de certificados se utilizan para comprobar que la clave pública (PK) contenida en un certificado objetivo (el primer certificado de la cadena) y demás datos que contiene pertenecen efectivamente a su titular. Para ello, se verifica la firma del certificado objetivo mediante la PK del certificado siguiente, cuya firma se verifica con el siguiente certificado, y así sucesivamente hasta llegar al último certificado de la cadena. Dado que el último certificado es un ancla de confianza, alcanzarlo con éxito demuestra que el certificado objetivo es fiable.

La descripción del párrafo anterior es una visión simplificada del proceso de validación de la ruta de certificación , [ 9 ] : §6 que implica comprobaciones adicionales, como verificar las fechas de validez de los certificados, buscar CRL , etc.

Ejemplo 1: Certificación cruzada entre dos PKI
Ejemplo 2: Renovación del certificado de CA

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 firmados con claves privadas diferentes (de distintas CA o de la misma CA). Por lo tanto, aunque un único certificado X.509 solo puede tener un emisor y una firma de CA, puede vincularse válidamente a más de un certificado, creando cadenas de certificados completamente diferentes. Esto es fundamental para la certificación cruzada entre PKI y otras aplicaciones. [ 15 ] Véanse los siguientes ejemplos:

Ejemplos

En estos diagramas:

  • Cada recuadro representa un certificado, cuyo asunto aparece en negrita.
  • A → B significa "A está firmado por B" (o, más precisamente, "A está firmado por la clave secreta correspondiente a la clave pública contenida en B").
  • Los certificados del mismo color (que no sean blancos/transparentes) contienen la misma clave pública.

Ejemplo 1: Certificación cruzada a nivel de Autoridad de Certificación (CA) raíz entre dos PKI.

Para gestionar que los certificados de usuario existentes en PKI 2 (como "Usuario 2") sean de confianza para PKI 1, CA1 genera un certificado (cert2.1) que contiene la clave pública de CA2. [ 16 ] 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 de confianza para PKI 2.

Ejemplo 2: Renovación del certificado de CA

Comprensión de la construcción de rutas de certificación (PDF) . Foro PKI. Septiembre de 2002. Archivado del original (PDF) el 4 de febrero de 2019. Recuperado el 7 de noviembre de 2014. Para permitir una transición fluida 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 privada de firma y un certificado que contenga la nueva clave pública firmada por la antigua clave privada de firma. Ambos certificados son autoemitidos, pero ninguno es autofirmado . Tenga en cuenta que estos son adicionales a los dos certificados autofirmados (uno antiguo, 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 de forma análoga para cert6. Esto permite que una parte que tenga el nuevo certificado raíz de la CA o el antiguo como ancla de confianza pueda confiar indistintamente en los certificados de usuario antiguos (como cert5) y en los nuevos (como cert6) durante la transición a las nuevas claves de la CA. [ 17 ]

Certificados X.509 de muestra

Este es un ejemplo de un certificado X.509 decodificado que fue utilizado anteriormente por wikipedia.org y otros sitios web de Wikipedia. Fue emitido por GlobalSign , como se indica en el campo Emisor. El campo Asunto describe a Wikipedia como una organización, y el campo Nombre Alternativo del Asunto (SAN) para DNS describe los nombres de host para los que podría utilizarse. El campo Información de Clave Pública del Asunto 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 de entidad final

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 correctamente configurado proporcionaría el certificado intermedio como parte del protocolo de enlace. Sin embargo, también es posible obtener el certificado intermedio consultando la URL de "Emisores de CA" del certificado de la entidad final.

Certificado intermedio

Este es un ejemplo de un certificado intermedio perteneciente a una autoridad de certificación . Este certificado firmó el certificado de entidad final mencionado anteriormente y fue firmado por el certificado raíz que se muestra a continuación. Observe que el campo "Asunto" de este certificado intermedio coincide con el campo "Emisor" del certificado de entidad final que firmó. Asimismo, el campo "Identificador de clave del sujeto" del certificado intermedio coincide con el campo "Identificador de clave de la autoridad" del certificado de entidad final.

Certificado raíz

Este es un ejemplo de un certificado raíz autofirmado que representa a una autoridad de certificación . Sus campos de emisor y sujeto son idénticos, y su firma puede validarse con su propia clave pública. La validación de la cadena de confianza debe finalizar aquí. Si el programa de validación dispone de este certificado raíz en su almacén de confianza , el certificado de la entidad final puede considerarse de confianza para su uso en una conexión TLS. De lo contrario, el certificado de la entidad final se considera no confiable.

Certificado: [ 18 ] 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=Root CA, CN=GlobalSign Root CA Validez No antes del: 1 de septiembre de 1998 a las 12:00:00 GMT No después del: 28 de enero de 2028 a las 12:00:00 GMT Asunto: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Información de la 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 la clave X509v3: crítico Firma de certificado, Firma 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: ...

Seguridad

Hay varias publicaciones sobre problemas de PKI de Bruce Schneier , Peter Gutmann y otros expertos en seguridad. [ 19 ] [ 20 ] [ 21 ]

Debilidades arquitectónicas

  • Uso de listas negras de certificados no válidos (mediante CRL y OCSP ),
    • Si el cliente solo confía en los certificados cuando las CRL están disponibles, pierde la capacidad sin conexión que hace atractiva la infraestructura de clave pública (PKI). Por lo tanto, la mayoría de los clientes confían en los certificados cuando las CRL no están disponibles, pero en ese caso un atacante que controle el canal de comunicación puede deshabilitar las CRL. Adam Langley, de Google, ha dicho que las comprobaciones de CRL con fallos leves son como un cinturón de seguridad que funciona excepto cuando hay un accidente. [ 22 ]
  • Las CRL son una opción particularmente mala debido a sus grandes tamaños y patrones de distribución complejos,
  • Semántica ambigua de OCSP y falta de estado de revocación histórica,
  • No se aborda la revocación de certificados raíz.
  • Problema de agregación : Las declaraciones de identidad (autenticación mediante un identificador), las declaraciones de atributos (envío de un conjunto de atributos verificados) y las declaraciones de políticas se combinan en un único contenedor. Esto plantea problemas de privacidad, asignación de políticas y mantenimiento.
  • Problema de delegación : Las CA no pueden, técnicamente, restringir a las CA subordinadas la emisión de certificados fuera de un espacio de nombres o conjunto de atributos limitado; esta característica de X.509 no se utiliza. Por lo tanto, existe un gran número de CA en Internet, y clasificarlas y sus políticas es una tarea insuperable. La delegación de autoridad dentro de una organización no se puede gestionar en absoluto, como en la práctica empresarial habitual. [ 23 ]
  • Problema de federación : Las cadenas de certificados resultantes de CA subordinadas, CA puente y firmas cruzadas hacen que la validación sea compleja y costosa en términos de tiempo de procesamiento. La semántica de validación de rutas puede ser ambigua. La jerarquía con una tercera parte de confianza es el único modelo viable. Esto resulta inconveniente cuando ya existe una relación de confianza bilateral.
  • La emisión de un certificado de validación extendida (EV) para un nombre de host no impide la emisión de un certificado de validación inferior válido para el mismo nombre de host, lo que significa que el nivel de validación superior de EV no protege contra ataques de intermediario. [ 24 ]

Problemas con las autoridades de certificación

  • La persona u organización que compra un certificado suele utilizar la autoridad de certificación más barata. En respuesta, las CA han reducido los precios y eliminado las comprobaciones de validación más costosas en lo que se conoce como una carrera hacia el abismo . Esta carrera hacia el abismo se aborda parcialmente con los certificados de validación extendida (EV) , pero el valor de confianza a ojos de los expertos en seguridad está disminuyendo. [ 25 ] Según Peter Gutmann , los certificados EV no añaden ningún control de seguridad adicional. Más bien, los certificados EV simplemente restablecen las ganancias de las CA a los niveles anteriores a la carrera hacia el abismo al permitirles cobrar más por un servicio que deberían haber estado proporcionando desde el principio. [ 4 ] La carrera hacia el abismo también se aborda parcialmente con autoridades de certificación como Let's Encrypt , que proporcionan certificados de forma gratuita. [ 26 ] Let's Encrypt también se ha convertido en el mayor proveedor de certificados, con más de 500 millones de sitios web que lo utilizan. [ 27 ] [ 28 ]
  • Las autoridades de certificación intentan negar casi todas las garantías al usuario y a las partes que confían en ellas en su Declaración de Prácticas de Certificación (CPS) . Por ejemplo, Apple Inc. declara en su CPS: «En la medida permitida por la ley aplicable, los acuerdos de suscripción, si corresponde, excluyen las garantías de Apple, incluidas las garantías de comerciabilidad o idoneidad para un propósito particular». [ 29 ]
  • Según Peter Gutmann, "Los usuarios utilizan un protocolo de solicitud de certificación no definido para obtener un certificado que se publica en una ubicación poco clara en un directorio inexistente sin medios reales para revocarlo" [ 21 ].
  • Como todas las empresas, las CA están sujetas a las jurisdicciones legales en las que operan y pueden verse obligadas legalmente a comprometer los intereses de sus clientes y usuarios. Las agencias de inteligencia también han utilizado certificados falsos emitidos mediante la vulneración extralegal de CA, como DigiNotar , para llevar a cabo ataques de intermediario . Otro ejemplo es la solicitud de revocación de la CA por parte del gobierno neerlandés, debido a una ley neerlandesa aprobada en 2018 que otorga nuevos poderes a los servicios de inteligencia y seguridad neerlandeses [ 30 ].

Problemas de implementación

Las implementaciones adolecen de fallos de diseño, errores, diferentes interpretaciones de los estándares y falta de interoperabilidad entre ellos. Algunos problemas son:

  • Muchas implementaciones desactivan la comprobación de revocación:
    • Consideradas un obstáculo, las políticas no se aplican.
    • Si estuviera activado por defecto en todos los navegadores, incluyendo la firma de código, probablemente colapsaría la infraestructura.
  • Los nombres distintivos son complejos y poco comprendidos (falta de canonización, problemas de internacionalización).
  • rfc822Name tiene dos notaciones
  • Las restricciones de nombre y política apenas se apoyan
  • Se ignora el uso de claves; se utiliza el primer certificado de la lista.
  • La aplicación de OID personalizados es difícil.
  • Los atributos no deben considerarse críticos porque provocan fallos en los clientes.
  • La longitud no especificada de los atributos da lugar a límites específicos del producto.
  • Existen errores de implementación en X.509 que permiten, por ejemplo, nombres de sujetos falsificados mediante cadenas terminadas en nulo [ 31 ] o ataques de inyección de código en certificados.
  • Al usar subidentificadores rellenos ilegales [ 32 ] 0x80 de identificadores de objetos , implementaciones incorrectas o al usar desbordamientos de enteros de los navegadores del cliente, un atacante puede incluir un atributo desconocido en el CSR, que la CA firmará, y que el cliente interpreta erróneamente como "CN" (OID=2.5.4.3). Dan Kaminsky demostró esto en el 26.º Congreso de Comunicación del Caos "Operaciones encubiertas de PKI" [ 33 ].

Debilidades criptográficas

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 vulnerabilidades de dicha función para falsificar certificados. En concreto, si un atacante logra producir una colisión de hash , puede convencer a una CA de firmar un certificado con contenido inocuo, cuyo hash es idéntico al de otro conjunto de contenido malicioso, creado por el atacante con valores de su elección. El atacante puede entonces añadir la firma proporcionada por la CA al contenido malicioso de su certificado, obteniendo así un certificado malicioso que aparenta estar firmado por la CA. Dado que el contenido del certificado malicioso es elegido exclusivamente por el atacante, puede tener fechas de validez o nombres de host diferentes a los del certificado inocuo. El certificado malicioso incluso puede contener un campo "CA: true", lo que le permite emitir otros certificados de confianza.

  • Los certificados basados ​​en MD2 se utilizaron durante mucho tiempo y eran vulnerables a ataques de preimagen . Dado que el certificado raíz ya tenía una autofirma, los atacantes podían usar esta firma para generar un certificado intermedio.
  • En 2005, Arjen Lenstra y Benne de Weger demostraron "cómo usar colisiones de hash para construir dos certificados X.509 que contienen firmas idénticas y que difieren solo en las claves públicas", logrado mediante un ataque de colisión en la función hash MD5 . [ 34 ]
  • En 2008, Alexander Sotirov y Marc Stevens presentaron en el Chaos Communication Congress un ataque práctico que les permitió crear una Autoridad de Certificación maliciosa, aceptada por todos los navegadores comunes, explotando el hecho de que RapidSSL todavía emitía certificados X.509 basados ​​en MD5. [ 35 ]
  • En abril de 2009, en la Conferencia Eurocrypt, [ 36 ] investigadores australianos de la Universidad Macquarie presentaron "Búsqueda automática de rutas diferenciales para SHA-1 ". [ 37 ] Los investigadores lograron deducir un método que aumenta la probabilidad de una colisión en varios órdenes de magnitud. [ 38 ]
  • En febrero de 2017, un grupo de investigadores liderado por Marc Stevens produjo una colisión SHA-1, demostrando la debilidad de SHA-1. [ 39 ]

Medidas de mitigación para las vulnerabilidades criptográficas

Para explotar una colisión de hash y falsificar firmas X.509, el atacante debe poder predecir los datos que firmará la autoridad de certificación. Esto se puede mitigar en cierta medida si la CA genera un componente aleatorio en los certificados que firma, generalmente el número de serie. El Foro CA/Navegador exige la entropía del número de serie en la Sección 7.1 de sus Requisitos Básicos desde 2011. [ 40 ]

A fecha de 1 de enero de 2016 Los requisitos básicos prohíben la emisión de certificados mediante SHA-1. A principios de 2017Chrome [ 41 ] y Firefox [ 42 ] rechazan los certificados que utilizan SHA-1. A partir de mayo de 2017 Tanto Edge [ 43 ] como Safari [ 44 ] también rechazan los certificados SHA-1. OpenSSL comenzó a rechazar los certificados SHA-1 por defecto en la versión 3.0, publicada en septiembre de 2021. [ 45 ]

Estándares PKI para X.509

  • PKCS7 (Estándar de sintaxis de mensajes criptográficos  : claves públicas con prueba de identidad para mensajes firmados y/o cifrados para PKI) [ ​​46 ]
  • Seguridad de la capa de transporte (TLS) y su predecesor SSL  : protocolos criptográficos para comunicaciones seguras en Internet. [ 47 ]
  • Protocolo de estado de certificado en línea (OCSP) [ 48 ] / lista de revocación de certificados (CRL) [ 9 ]  : esto sirve para comprobar el estado de revocación de certificados.
  • PKCS12 (Estándar de sintaxis para el intercambio de información personal)  : se utiliza para almacenar una clave privada con el certificado de clave pública correspondiente [ 49 ].
  • RFC 4158 — Creación de rutas de certificación — orientación y recomendaciones para crear rutas de certificación de clave pública X.509 dentro de las aplicaciones (es decir, validar un certificado de entidad final utilizando un certificado de CA). 

Grupo de trabajo PKIX

En 1995, el Grupo de Trabajo de Ingeniería de Internet, en colaboración con el Instituto Nacional de Estándares y Tecnología [ 50 ], formó el grupo de trabajo de Infraestructura de Clave Pública (X.509). Este grupo, que concluyó en junio de 2014, [ 51 ] se conoce comúnmente como "PKIX". Elaboró ​​RFC y otra documentación estándar sobre el uso y la implementación práctica de X.509. En particular, produjo el RFC 3280 y su sucesor, el RFC 5280, que definen cómo utilizar X.509 en los protocolos de Internet. 

Principales protocolos y estándares que utilizan certificados X.509

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 Wi-Fi. 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 OpenCable define su propio perfil de X.509 para su uso en la industria del cable.

Dispositivos como las tarjetas inteligentes y los TPM suelen llevar certificados para identificarse a sí mismos o a sus propietarios. Estos certificados tienen formato X.509.

El estándar WS-Security define la autenticación ya sea a través de TLS o a través de su propio perfil de certificado. [ 18 ] Ambos métodos utilizan X.509.

El sistema de firma de código Microsoft Authenticode utiliza X.509 para identificar a los autores de los programas informáticos. La función de arranque seguro de UEFI utiliza X.509 para autenticar los controladores o gestores de arranque de UEFI durante el arranque y bloquear los controladores o gestores de arranque incluidos en la lista negra (mediante el intercambio de claves prohibidas o la base de datos dbx). [ 52 ]

El estándar de comunicación para automatización industrial OPC UA utiliza X.509.

SSH generalmente utiliza un modelo de seguridad de confianza en el primer uso y no necesita certificados. Sin embargo, la popular implementación OpenSSH sí admite un modelo de identidad firmada por una CA basado en su propio formato de certificado no X.509. [ 53 ]

Véase también

Referencias

  1. 1 2 "X.509: Tecnología de la información - Interconexión de sistemas abiertos - El directorio: Marcos de certificados de clave pública y de atributos" . UIT . Consultado el 6 de noviembre de 2019 .
  2. 1 2 Hesse, Peter; Cooper, Matt; Dzambasow, Yuriy A.; Joseph, Susan; Nicholas, Richard (septiembre de 2005). Infraestructura de clave pública X.509 de Internet: construcción de ruta de certificación . Grupo de trabajo de redes. doi : 10.17487/RFC4158 . RFC 4158 .Informativo.
  3. ↑ Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (mayo de 2008). Certificado de infraestructura de clave pública X.509 de Internet y perfil de lista de revocación de certificados (CRL) . IETF . doi : 10.17487/RFC5280 . RFC 5280 .Estándar propuesto. Actualizado por las RFC 9549 , 9598 , 8398 , 8399 y 6818. Sustituye a las RFC 4630 , 4325 y 3280. A continuación se presenta una vista simplificada del modelo arquitectónico que asume la Infraestructura de Clave Pública utilizando las especificaciones X.509 (PKIX).  
  4. 1 2 3 4 Gutmann, Peter (abril de 2014). "Ingeniería de la seguridad" (PDF) .
  5. ↑ Housley, R.; Hoffman, P. (mayo de 1999). Protocolos operativos de la infraestructura de clave pública X.509 de Internet: FTP y HTTP . Grupo de trabajo de redes. doi : 10.17487/RFC2585 . RFC 2585 .Norma propuesta. sec. 4: Registros MIME.
  6. ↑ "x509Certificate" . Documentación para desarrolladores de Apple: Identificadores de tipo uniforme . Apple Inc.
  7. ↑ "CA:IncludedCAs" . Wiki de Mozilla . Consultado el 17 de enero de 2017 .
  8. ↑ "Error 110161 - (ocspdefault) habilitar OCSP por defecto" . Mozilla . Consultado el 17 de marzo de 2016 .
  9. 1 2 3 4 5 6 7 8 Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (mayo de 2008). Certificado de infraestructura de clave pública X.509 de Internet y perfil de lista de revocación de certificados (CRL) . IETF . doi : 10.17487/RFC5280 . RFC 5280 .Estándar propuesto. Actualizado por RFC 9549 , 9598 , 8398 , 8399 y 6818. Deja obsoletas las RFC 4630 , 4325 y 3280 .  
  10. ↑ Nelson B Boyard (9 de mayo de 2002). "Todo sobre las extensiones de certificados" . Mozilla. Archivado del original el 15 de diciembre de 2018. Recuperado el 10 de septiembre de 2020 .
  11. ↑ "La interfaz de usuario de EV se traslada a la información de la página" . Documentación de Chromium . 2021. Consultado el 12 de julio de 2025 .
  12. ↑ "Indicadores de seguridad y privacidad mejorados en Firefox 70" . Blog de seguridad de Mozilla . 15 de octubre de 2019. Consultado el 12 de julio de 2025 .
  13. ↑ "Los certificados de validación extendida están (realmente, realmente) muertos" . Troy Hunt . 13 de agosto de 2019. Consultado el 12 de julio de 2025 .
  14. ↑ sysadmin1138 (19 de mayo de 2009). "¿Qué es un archivo PEM y en qué se diferencia de otros formatos de archivos de claves generadas por OpenSSL?" . Server Fault . Consultado el 19 de octubre de 2023 .{{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 . 
  15. ↑ Lloyd, Steve (septiembre de 2002). Comprensión de la construcción de rutas de certificación (PDF) . Foro PKI. Archivado del original (PDF) el 4 de febrero de 2019. Consultado el 7 de noviembre de 2014 .
  16. ↑ "Certificación cruzada entre CA raíz". Escenarios de implementación de subordinación calificada . Microsoft. Agosto de 2009.
  17. ↑ Nash; Duane; Joseph; Brink (2001). "Ciclos de vida de claves y certificados. Renovación de certificados CA". PKI: Implementación y gestión de la seguridad electrónica . RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3.
  18. 1 2 "Web Services Security X.509 Token Profile Version 1.1.1" . Oasis . Consultado el 14 de marzo de 2017 .
  19. ↑ Carl Ellison y Bruce Schneier. "Los 10 principales riesgos de PKI" (PDF) . Computer Security Journal (Volumen XVI, Número 1, 2000). Archivado del original (PDF) el 24 de noviembre de 2015. Consultado el 2 de abril de 2014 .
  20. ↑ Peter Gutmann . "PKI: no está muerta, solo descansa" (PDF) . IEEE Computer (Volumen: 35, Número: 8).
  21. 1 2 Gutmann, Peter . "Todo lo que nunca quisiste saber sobre PKI pero te viste obligado a descubrir" (PDF) . Recuperado el 14 de noviembre de 2011 .
  22. ↑ Langley, Adam (5 de febrero de 2012). "Comprobación de revocación y CRL de Chrome" . Imperial Violet . Recuperado el 2 de febrero de 2017 .
  23. ↑ "Ejemplo de plan de negocios de sistemas de seguridad [ 2021 ] " . OGScapital . 27 de enero de 2014. Archivado del original el 9 de julio de 2021. Consultado el 30 de junio de 2021 .
  24. ↑ Michael Zusman; Alexander Sotirov (julio de 2009). "Sub-Prime PKI: Attacking Extended Validation SSL" (PDF) . Blackhat . Consultado el 10 de septiembre de 2020 .
  25. ↑ Hunt, Troy (17 de septiembre de 2018). "Los certificados de validación extendida han muerto" . TroyHunt.com . Consultado el 26 de febrero de 2019 .
  26. ↑ "Let's Encrypt" . Let's Encrypt . 10 de julio de 2023. Consultado el 8 de abril de 2025 .
  27. ↑ "Por una mejor Internet - Informe anual de ISRG 2020" (PDF) . Grupo de Investigación sobre Seguridad en Internet . 17 de noviembre de 2020. Consultado el 11 de mayo de 2021 .
  28. ↑ "Estadísticas de Let's Encrypt" . Let's Encrypt . 10 de julio de 2023. Consultado el 8 de abril de 2025 .
  29. ↑ "Autoridad de Certificación - Declaración de Prácticas de Certificación" (PDF) . Versión 6.1. Apple, Inc. 19 de agosto de 2016.
  30. ^ van Pelt, Cris. "Logius: problema de confianza de CA del gobierno holandés" . Bugzilla . Consultado el 31 de octubre de 2017 .
  31. ↑ Moxie Marlinspike (2009). "Más trucos para derrotar a SSL en la práctica" (PDF) . Instituto de Estudios Disruptivos. Blackhat . Recuperado el 10 de septiembre de 2020 .
  32. ↑ Recomendación ITU-T X.690, cláusula 8.19.2
  33. ↑ Dan Kaminsky (29 de diciembre de 2009). "26C3: Operaciones encubiertas de PKI" . Blog de eventos de CCC . Der Chaos Computer Club . Consultado el 29 de septiembre de 2013 .
  34. ↑ Lenstra, Arjen; de Weger, Benne (19 de mayo de 2005). Sobre la posibilidad de construir colisiones de hash significativas para claves públicas (PDF) (Informe técnico). Lucent Technologies, Bell Laboratories y Technische Universiteit Eindhoven. Archivado (PDF) del original el 14 de mayo de 2013. Recuperado el 28 de septiembre de 2013 .
  35. ↑ "MD5 considerado dañino hoy en día" . Universidad Tecnológica de Eindhoven. 16 de junio de 2011. Consultado el 29 de septiembre de 2013 .
  36. ↑ "Eurocrypt 2009" . Asociación Internacional para la Investigación Criptológica.
  37. ↑ Cameron McDonald; Philip Hawkes; Josef Pieprzyk (2009). "Colisiones SHA-1 ahora" (PDF) . Universidad Macquarie y Qualcomm . Recuperado el 10 de septiembre de 2020 .
  38. ↑ Dennis Dwyer (2 de junio de 2009). "Ataques de colisión SHA-1 ahora 252" . SecureWorks Insights . Recuperado el 24 de febrero de 2016 .
  39. ↑ Marc Stevens; Elie Bursztein; Pierre Karpman; Ange Albertini; Yarik Markov. "La primera colisión para SHA-1 completo" (PDF) . CWI Amsterdam y Google Research. Archivado del original (PDF) el 15 de mayo de 2018. Recuperado el 10 de septiembre de 2020 a través de Shattered.
  40. ↑ "Documentos de requisitos básicos" . Foro de navegadores CA. Consultado el 19 de marzo de 2017 .
  41. ↑ Andrew Whalley (16 de noviembre de 2016). "Certificados SHA-1 en Chrome" . Blog de seguridad en línea de Google . Consultado el 19 de marzo de 2017 .
  42. ↑ "El fin de SHA-1 en la web pública" . Blog de seguridad de Mozilla . 23 de febrero de 2017. Consultado el 19 de marzo de 2017 .
  43. ↑ "Aviso de seguridad de Microsoft 4010323" . Technet . Microsoft . Consultado el 16 de mayo de 2017 .
  44. ↑ "Safari y WebKit no admiten certificados SHA-1" . Soporte técnico de Apple . 16 de agosto de 2018. Consultado el 10 de septiembre de 2020 .
  45. ↑ "openssl/NEWS.md en master · openssl/openssl" . GitHub . Consultado el 16 de febrero de 2025 .
  46. ↑ B. Kaliski (marzo de 1998). PKCS #7: Sintaxis de mensajes criptográficos versión 1.5 . Grupo de trabajo de redes. doi : 10.17487/RFC2315 . RFC 2315 .Informativo.
  47. ↑ T. Dierks; E. Rescorla (agosto de 2008). El protocolo Transport Layer Security (TLS) versión 1.2 . Grupo de trabajo TLS de la IETF . doi : 10.17487/RFC5246 . RFC 5246 .Obsoleto. Obsoleto según RFC 8446. Obsoleto según RFC 3268 , 4346 y 4366 ; actualiza RFC 4492 .   
  48. ↑ S. Santesson; M. Myers; R. Ankey; S. Galperin; C. Adams (junio de 2013). Protocolo de estado de certificado en línea de infraestructura de clave pública de Internet X.509 - OCSP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6960 . RFC 6960 .Estándar propuesto. Actualizado por RFC 8954. Deja obsoletas las RFC 6277 y 2560. Actualiza la RFC 5912 .   
  49. ↑ "PKCS 12: Estándar de sintaxis para el intercambio de información personal" . EMC.com . RSA Laboratories. Archivado del original el 6 de julio de 2017. Consultado el 19 de marzo de 2017 .
  50. ↑ "Infraestructura de clave pública (X.509) (pkix) - Carta" . IETF Datatracker . Grupo de trabajo de ingeniería de Internet . Consultado el 1 de octubre de 2013 .
  51. ↑ "Páginas de estado de Pkix" . Herramientas IETF . Consultado el 10 de marzo de 2017 .
  52. ↑ Smith, Roderick W. (2012-11-04). "Administración de cargadores de arranque EFI para Linux: Control del arranque seguro (Administración de claves desde Linux)" . Página web de Roderick W. Smith . Consultado el 20 de febrero de 2025 .
  53. ↑ "Cómo crear una CA SSH para validar hosts y clientes con Ubuntu" . DigitalOcean . Consultado el 19 de marzo de 2017 .
  • Estándares X.509 de la UIT-T
  • Artículos de Peter Gutmann:
    • Descripción general de PKI
    • Notas de implementación y guía de estilo de X.509
  • Preguntas frecuentes sobre criptomonedas de RSA Labs . RSA Laboratories. Archivado del original el 30 de diciembre de 2006.
  • Directrices de código seguro Sun
  • RFC 4158 – " Infraestructura de clave pública X.509 de Internet: Creación de rutas de certificación " , Informativo. 
  • RFC 5280 – " Perfil de certificado y lista de revocación de certificados (CRL) de la infraestructura de clave pública X.509 de Internet " , Norma propuesta. 
  • Comprensión de los certificados digitales - Microsoft TechNet
Obtenido de " https://en.wikipedia.org/w/index.php?title=X.509&oldid=1361031787#History_and_usage "