X.509 es un estándar que especifica formatos para certificados de clave pública, listas de revocación de certificados, atributos de certificado y un algoritmo de validación de ruta de certificación, definido por la Unión Internacional de Telecomunicaciones (UIT). X.509 establece, entre otras cosas, un formato de certificado electrónico estándar y un algoritmo para la validación de la ruta de certificación. X.509 también han sido numerosos RFC del IETF .
X.509 se creó en 1988 como parte del estándar X.500 . Se basa en un sistema jerárquico de autoridades de certificación , a diferencia de las redes de confianza (como la web de confianza OpenPGP ), donde cualquiera puede firmar los certificados de otros.
En el sistema X.509, una autoridad de certificación asigna un certificado que vincula una clave pública a un Nombre distinguido cuyo formato está definido por la recomendación X.500 , oa un nombre alternativo ( Nombre alternativo ) como '' una dirección de correo electrónico o DNS. registro .
Este certificado coloca la firma de una autoridad de certificación en el último campo. Concretamente, esta firma se realiza mediante un condensado de todos los campos anteriores del certificado y un cifrado de este condensado por la clave privada de la autoridad de certificación. Cualquiera que tenga la clave pública para esa CA puede descifrar el hash y compararlo con su propio cálculo de hash de certificado. Si los dos condensados son idénticos, esto garantiza que el certificado está intacto, no ha sido modificado. El certificado de la CA que contiene su clave pública puede a su vez ser firmado por otro certificado de nivel superior, formando así una cadena. En la parte superior de la cadena se encuentran los certificados más importantes: los certificados raíz .
Los certificados raíz son claves públicas sin firmar o autofirmadas en las que confía. El software, como los navegadores web o los clientes de correo electrónico, tiene certificados raíz de muchas autoridades de certificación comerciales o gubernamentales. Cuando un navegador abre una conexión segura ( TLS / SSL ) a un sitio que tiene un certificado emitido por una autoridad conocida, considera que el sitio es seguro siempre que se valide la ruta de certificación. El cambio al modo seguro es transparente.
Si el software (navegador u otro) no conoce la autoridad de certificación (certificado generado y autofirmado por una persona o autoridad de certificación aún no conocida o eliminada voluntariamente de la lista de autoridades aceptadas), el navegador propone examinar el certificado, entonces aceptarlo o rechazarlo según la confianza depositada en él.
X.509 se puede utilizar con S / MIME , TLS / SSL , SET e IPsec .
La definición original está disponible en RFC 2459 (sección 4) o en la última versión ( RFC 5280), que contiene una especialización de X.509 para aplicaciones de Internet . La parte autenticada contiene los siguientes campos:
Los nombres del remitente (también signatario) y del titular son nombres X.501, que también se pueden encontrar en los directorios ISO y LDAP . El contenido anterior va seguido de una repetición del algoritmo de firma y la propia firma.
Ninguno de los campos obligatorios permite distinguir una autoridad de certificación (una organización que emite certificados) de un simple titular. La extensión basicConstraints definida en X.509 versión 3 aborda esta limitación. Otra imperfección del mismo tipo es que solo el nombre permite vincular un certificado al de su emisor, mientras que no se puede garantizar la unicidad de los nombres.
El RFC 5280 define una suma de extensiones que indican el uso previsto del certificado. Estas son las extensiones más comunes:
En general, si un certificado tiene varias extensiones que restringen su uso, se deben cumplir todas las condiciones para que el uso sea apropiado. El RFC 5280 da el ejemplo específico de un certificado que contiene tanto keyUsage extendedKeyUsage y, en este caso, se deben cumplir las dos restricciones para que el certificado pueda utilizarse de acuerdo con los usos previstos.
Estas son las extensiones comunes de certificados en formato X.509:
Una cadena de certificados es una lista de certificados (comenzando con una entidad a certificar, como un servidor) que comprende una o más autoridades de certificación (la última firmada por ella misma), que tiene las siguientes propiedades:
Cadenas de certificados se utilizan para garantizar que la clave pública y de datos del certificado (el 1 st de la cadena) corresponden al propietario de la misma. Pour s'en assurer, la signature numérique est vérifiée à l'aide de la clé publique de l'entité suivante dans la chaîne, elle-même signée par la clé publique de l'entité suivante jusqu'à arriver à la dernière entité de la cadena. Como se considera el último certificado de fiar, que se remonta a ella en última instancia, que equivale a la autenticación del 1 st certificado.
Un certificado puede volverse inválido por muchas razones tales como vencimiento natural (excediendo la fecha de validez), pérdida o compromiso de la clave privada asociada con el certificado, el cambio de al menos un campo incluido en el nombre del titular / titular del certificado y extremo caso de pérdida o compromiso de la clave privada de la autoridad de certificación que firmó el certificado en cuestión.
Es por eso que el estándar define el formato de una lista que indica los certificados que han dejado de ser válidos para una determinada autoridad de certificación. Esta lista está firmada por la autoridad de certificación para evitar cualquier modificación por parte de una persona no autorizada.
Incluye una fecha de emisión, una fecha de actualización (ambas opcionales) y la propia lista en forma de pares (número de serie del certificado revocado; posible motivo de revocación) . El patrón solo puede estar presente en las CRL en el formato de la versión 2.
Una limitación a veces molesta de las CRL es el retraso en la propagación de la información de revocación. Para reducir esto, se ha desarrollado el protocolo de validación de certificados OCSP . Definido inicialmente en RFC 2560 y luego nuevamente en RFC 6960, este protocolo proporciona aproximadamente la misma información que las CRL, pero potencialmente más actualizado.
Tras la publicación de un ataque de búsqueda de colisión completo contra MD5 en 2004, Arjen Lenstra , Wang Xiaoyun y Benne de Weger se interesaron en X.509 utilizando MD5 para la autenticación de certificados. Su ataque resultó en la falsificación de dos certificados con firmas idénticas.
El uso de la función hash criptográfica SHA-1 solo resuelve parcialmente el problema, ya que teóricamente es posible un ataque similar, aunque la complejidad de encontrar colisiones en SHA-1 es mucho mayor que en MD5.
Soluciones:
Autoridades de certificación:
Herramientas (gratis):