propósito típico de los certificados autofirmados

Mientras que con Vamos a cifrar ofreciendo certificados de forma gratuita y hoy fácilmente elimina el argumento "no cuesta nada", hay Todavía hay razones por las que los certificados autofirmados pueden ser útiles, por ejemplo,

• para fines de prueba (ninguna CA le otorga un certificado para su dominio local como testing.testenv.cooperation)
• en redes locales (para proteger las interfaces web de los enrutadores, por ejemplo),
• como certificados de cliente,
• para S / MIME,
• contrarrestar los problemas de las AC en general.

La única diferencia real es que un certificado firmado por una entidad emisora de certificados (generalmente) es de confianza sin solicitarle al usuario una entrada, mientras que un certificado autofirmado necesita que el usuario lo valide y confíe, por ejemplo, comprobando la huella digital a través de un canal de confianza. Una vez que se ha depositado la confianza en el certificado autofirmado, es tan bueno como el certificado firmado por CA (sin contar los problemas de reinversión).

Los certificados autofirmados pueden ser útiles cuando alguien no confía en que la CA no cree un certificado para un MITM, por ejemplo.

Otra gran aplicación de certificados autofirmados (o, en general, "certificados no firmados por CA") pueden ser certificados de cliente: una aplicación web puede crear certificados para usuarios autenticados y usarlos para autenticarlos desde ese punto en adelante: certificado La autenticación basada en sistemas es mucho mejor en términos de seguridad que los esquemas de nombre de usuario / contraseña tradicionales y se usa a menudo para aplicaciones B2B y aplicaciones móviles.

El uso de certificados S / MIME autofirmados hace que S / MIME sea tan conveniente como GPG con la necesidad de validar los certificados manualmente (ver arriba), pero hay casos extremos en los que alguien sin confianza en una CA puede tener acceso a S / Cifrado MIME pero no GPG (usuarios de iPhone, por ejemplo, así como algunos clientes de correo electrónico corporativo)

Considere el caso en el que controla la cadena de verificación del certificado raíz tanto en el servidor como en el cliente (este sería el caso cuando desarrolle ambos componentes). Esto podría incluir escenarios como:

• Ejecutando su propio correo electrónico, base de datos o servidor web que solo podrán usar las personas cuyos certificados de confianza puede controlar;

• Desarrollar un punto final o una aplicación móvil que se comunique con su propio servidor;

Aquí, usar un certificado autofirmado tiene más sentido que los certificados firmados por CA. Las ventajas obvias incluyen:

• Control total sobre la vida útil del certificado, que le permite, por ejemplo, firmar los certificados de "evaluación" para que tengan una validez de tan solo una semana;

• Control total sobre el contenido del certificado. Por ejemplo, puede almacenar la información de licencia en el campo CNAME del certificado de cliente, como "10 estaciones de trabajo". Incluso para los servidores, también puede emitir certificados comodín, que es algo que Let's Encrypt no hará por usted (y que generalmente cuesta un poco).

• Usted conoce las propiedades de seguridad de todo el sistema. Esto permite una mejor afirmación de los riesgos, incluidos los riesgos de coerción de los estados-nación;

• Puedes firmar certificados sobre la marcha. Esto es útil en ciertos casos (lo usé al implementar el equilibrio dinámico de carga);

• Y, por supuesto, es (casi) gratuito.