¿Cuáles son los riesgos de un certificado de cliente autofirmado?

Question

¿Cuáles son los riesgos de un certificado de cliente autofirmado?

#1 de Tobi Nary (2 votos)
#2 de entrop-x (0 votos)

0

Comprendo los riesgos de un certificado autofirmado utilizado para habilitar HTTPS en un servidor.

Sin embargo, mi pregunta es acerca de los certificados HTTPS cliente .

Imagina el siguiente escenario. Quiero poder autenticar a un grupo de usuarios expertos en tecnología en un sitio web público sin necesidad de que pasen por OpenID o que requieran una contraseña.

Empiezo generando un certificado raíz autofirmado que almaceno en el servidor. En el contexto de esta pregunta, asumamos que este certificado raíz estará protegido contra hackers.

Desde este certificado raíz, genero varios certificados de cliente, uno para cada usuario, y transmito el archivo .p12 a esos usuarios de manera segura . Añaden esos certificados a sus navegadores y ahora pueden autenticarse.

¿Hay algún problema de seguridad que indique que el certificado raíz se autofirmó? ¿Cómo se compararía esto, por ejemplo, con el uso del certificado derivado de Let's Encrypt como un certificado raíz (lo cual es posible, ya que también tengo la clave privada en el servidor)?

Me parece que en términos de revocación de certificados, es tan simple como regenerar el certificado, sería el certificado raíz si este fuera el problema, o un certificado del cliente. ¿Hay algo más que me esté perdiendo?

cryptography certificates

pregunta Arseni Mourzenko 02.12.2017 - 10:52

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography certificates

¿Cómo puedo desbloquear la unidad sin la contraseña o la clave de recuperación de Bitlocker? [duplicar] ¿Cómo verificar si algunos cifrados están deshabilitados en OpenSSL?

score 2 · Answer 1

Lo que está haciendo allí básicamente se está convirtiendo en su propia autoridad de certificación, lo que está bien, siempre y cuando acepte los riesgos asociados y / o los mitigue.

En este escenario, puede basar de forma segura la confianza de sus servidores en su propio certificado para emitir certificados de clientes siempre que esté de acuerdo con su propio método de CA para establecer la confianza en la identidad de los usuarios.

No estoy muy seguro de que encriptar le otorgaremos un certificado que tenga establecido el atributo CA (es decir, puede actuar como una autoridad de certificación). Si bien es posible que tenga la clave para el certificado, ese certificado no permite firmar certificados en sí mismo.

La revocación del certificado debe manejarse internamente (su servidor debe saber qué certificados ya no deben aceptarse) al menos; no es necesario que proporcione CRL si solo utiliza la CA internamente.

También puede establecer una conexión 1: 1 entre el usuario y el certificado, y la sustitución del certificado revocado por una nueva debería estar bien.

score 0 · Answer 2

Creo que uno debería volver a lo básico para ver el problema o no de este. Los certificados son una forma de utilizar un tercero de confianza, llamado Autoridad de Certificación, para saber que una clave pública es de hecho la clave pública de la entidad que dice ser. Si tiene una forma segura de dar una clave privada a alguien (el .p12), por supuesto que conoce la clave pública que la acompaña, no tiene dudas sobre su origen. No necesitas ningún "certificado". No necesita ningún tercero de confianza para asegurarse de que la clave pública que usted mismo generó va con la clave privada que proporcionó de manera segura (según su suposición) al cliente en cuestión. De hecho, estás reinventando un tipo de ssh pero con claves incrustadas en certificados de los que las firmas no importan aquí.

Un certificado autofirmado no es otra cosa que una clave pública en un formato elegante. Cualquiera que genere una clave pública (y la clave privada que la acompaña) también puede generar el certificado autofirmado que la acompaña. El tercero de confianza es aquí el proveedor de la clave pública. En la medida en que puede confiar en él, puede confiar directamente en la clave pública y no necesita un certificado; y en la medida en que no se puede confiar directamente en el origen de la clave pública (que fue la razón para utilizar certificados en primer lugar), entonces tampoco se puede confiar en el firmante del certificado porque es el mismo.

Al igual que en su aplicación, que no es más que una aplicación típica de tipo ssh, el software necesita certificados, usted incrusta las claves en un certificado, pero estas firmas no tienen ningún significado de seguridad aquí.