stringtranslate.com

Certificado autofirmado

En criptografía y seguridad informática , los certificados autofirmados son certificados de clave pública que no son emitidos por una autoridad de certificación (CA). Estos certificados autofirmados son fáciles de crear y no cuestan dinero. Sin embargo, no aportan ningún valor de confianza.

Por ejemplo, si el propietario de un sitio web utiliza un certificado autofirmado para proporcionar servicios HTTPS, las personas que visitan ese sitio web no pueden estar seguras de que están conectadas al destino previsto. Por lo que saben, un tercero malintencionado podría estar redirigiendo la conexión utilizando otro certificado autofirmado que tenga el mismo nombre de titular. La conexión sigue estando cifrada, pero no conduce necesariamente al destino previsto. En comparación, un certificado firmado por una CA de confianza evita este ataque porque el navegador web del usuario valida por separado el certificado con la CA emisora. El certificado del atacante no supera esta validación.

Beneficios

Los certificados autofirmados se pueden crear de forma gratuita, utilizando una amplia variedad de herramientas, entre las que se incluyen OpenSSL , keytool de Java, Adobe Reader, wolfSSL y Keychain de Apple. Son fáciles de personalizar; por ejemplo, pueden tener tamaños de clave más grandes o contener metadatos adicionales. Su uso no implica los problemas de confiar en terceros que pueden firmar certificados de forma incorrecta. Las transacciones de certificados autofirmados suelen presentar una superficie de ataque mucho menor al eliminar tanto la compleja validación de la cadena de certificados [1] como las comprobaciones de revocación de certificados como CRL y OCSP .

Problemas de confianza

En un sistema PKI basado en CA , las partes que participan en una comunicación segura deben confiar en una CA, es decir, colocar los certificados de CA en una lista blanca de certificados de confianza. Los desarrolladores de navegadores web pueden utilizar los procedimientos especificados por el CA/Browser Forum para incluir en la lista blanca a autoridades de certificación públicas y conocidas. Los grupos y empresas individuales pueden incluir en la lista blanca certificados de CA privados adicionales. Los problemas de confianza de una entidad que acepta un nuevo certificado autofirmado son similares a los problemas de una entidad que confía en la adición de un nuevo certificado de CA. Las partes en una PKI autofirmada deben establecer confianza entre sí (utilizando procedimientos fuera de la PKI) y confirmar la transferencia precisa de claves públicas, por ejemplo, comparando el hash criptográfico del certificado fuera de banda.

Existen muchas diferencias sutiles entre los certificados firmados por una CA y los certificados autofirmados, especialmente en el grado de confianza que se puede depositar en las afirmaciones de seguridad del certificado. Algunas CA pueden verificar la identidad de la persona a la que emiten un certificado; por ejemplo, el ejército de los EE. UU. emite sus tarjetas de acceso común en persona, junto con múltiples formas de identificación. La CA puede certificar valores de identidad como estos incluyéndolos en el certificado firmado. La entidad que valida el certificado puede confiar en la información contenida en ese certificado, en la misma medida en que confía en la CA que lo firmó (y, por implicación, en los procedimientos de seguridad que la CA utilizó para verificar la información certificada).

En cambio, con un certificado autofirmado, la confianza en los valores del certificado es más complicada porque la entidad posee la clave de firma y siempre puede generar un nuevo certificado con valores diferentes. Por ejemplo, es posible que no se confíe en las fechas de validez de un certificado autofirmado porque la entidad siempre podría crear y firmar un nuevo certificado que contuviera un intervalo de fechas válido.

Los valores de un certificado autofirmado solo pueden ser confiables cuando se verificaron fuera de banda durante la aceptación del certificado y existe un método para verificar que el certificado autofirmado no haya cambiado después de que se haya otorgado confianza. Por ejemplo, el procedimiento para otorgar confianza a un certificado autofirmado incluye una verificación manual de las fechas de validez y se incorpora un hash del certificado a la lista blanca. [2] Cuando se presenta el certificado a una entidad para que lo valide, primero se verifica que el hash del certificado coincida con el hash de referencia en la lista blanca y, si coinciden (lo que indica que el certificado autofirmado es el mismo que el que se otorgó confianza anteriormente), entonces se puede confiar en las fechas de validez del certificado. En el RFC 3280 se puede encontrar un tratamiento especial de los campos de certificado X.509 para certificados autofirmados. [1]

La revocación de certificados autofirmados difiere de la de los certificados firmados por una CA. Por naturaleza, ninguna entidad (CA u otras) puede revocar un certificado autofirmado. Sin embargo, se podría invalidar un certificado autofirmado eliminándolo de la lista blanca de confianza. [3]

Usos

Los certificados autofirmados tienen usos limitados, por ejemplo, en los casos en que el emisor y el usuario único son la misma entidad. Por ejemplo, el sistema de cifrado de archivos de Microsoft Windows emite un certificado autofirmado en nombre de una cuenta de usuario para cifrar y descifrar archivos de forma transparente sobre la marcha. Otro ejemplo es un certificado raíz , que es una forma de certificado autofirmado.

Confusión de nombres

Los términos "autofirmado" y "autoemitido" se utilizan ocasionalmente de manera intercambiable y "certificado autofirmado" a veces incluso se utiliza incorrectamente para indicar un certificado emitido por una CA privada (no de confianza pública). [4] [5] [6]

El RFC 5280 define los certificados autofirmados como "certificados autoemitidos en los que la firma digital puede verificarse mediante la clave pública vinculada al certificado" [7], mientras que un certificado autoemitido es un certificado "en el que el emisor y el sujeto son la misma entidad". Si bien en sentido estricto el RFC establece esta definición solo para los certificados de CA, no hay razón para adoptar también esa definición para los certificados de entidad final.

Véase también

Referencias

  1. ^ ab Housley, Russ; Polk, Tim; Ford, Warwick S.; Solo, David (mayo de 2002). "Perfil de certificado y CRL – RFC 3280". tools.ietf.org . Archivado desde el original el 26 de abril de 2017 . Consultado el 6 de abril de 2017 .
  2. ^ "Cómo evitar SSLHandshakeException". Archivado desde el original el 2021-08-01 . Consultado el 2021-08-01 .
  3. ^ "RFC 2459: Perfil de CRL y certificado de infraestructura de clave pública X.509 de Internet". www.ietf.org . Enero de 1999. Archivado desde el original el 14 de diciembre de 2012 . Consultado el 3 de enero de 2009 .
  4. ^ "Cómo crear certificados SSL autofirmados de confianza y dominios locales para realizar pruebas". 3 de noviembre de 2020. Un certificado autofirmado es un certificado firmado por la persona que lo crea . Consultado el 15 de febrero de 2024 .
  5. ^ "Generar un certificado autofirmado de Azure Application Gateway con una CA raíz personalizada". 17 de enero de 2024. Consultado el 15 de febrero de 2024 .
  6. ^ "Creación de un certificado SSL autofirmado y confiable para el navegador | por Thijs Busser | Medium". Un certificado SSL autofirmado para el desarrollo de sitios web necesita un certificado raíz . Consultado el 15 de febrero de 2024 .
  7. ^ Boeyen, Sharon; Santesson, Stefan; Polk, Tim; Housley, Russ; Farrell, Stephen; Cooper, David (mayo de 2008). "Perfil de certificado de infraestructura de clave pública de Internet X.509 y lista de revocación de certificados (CRL)".
  8. ^ "Beta pública". Let's encrypt . Archivado desde el original el 7 de abril de 2018. Consultado el 6 de diciembre de 2015 .