Aclarar los certificados autofirmados frente a la autoridad de certificado raíz

9

Espero que alguien pueda ayudarme a comprender algunos aspectos básicos de los certificados SSL que he tenido problemas para encontrar en documentos, Wikipedia y casi en cualquier otro lugar de Internet.

Estoy trabajando en una aplicación que se comunica con otra en una red separada. Cada aplicación actúa como un cliente y un servidor en comunicación bidireccional. Utilizarán los servicios REST a través de HTTPS con el firewall de cada red abierto explícitamente para el otro. Todos los certificados SSL serán autofirmados. Mi solicitud está escrita en Java, pero no estoy seguro de la otra.

Yo creo Tengo dos opciones para establecer las conexiones HTTPS con certificados autofirmados:

  1. El Marco subyacente de cada aplicación (por ejemplo, Java) instala el certificado autofirmado de la otra, lo que da como resultado ese marco, y no necesariamente el SO más amplio, confiando en el certificado
  2. Cada servidor instala el certificado del otro como una Autoridad de certificación raíz y, por lo tanto, confía en cualquier certificado autofirmado producido por el otro servidor. Un marco como Java debería reconocer esta Autoridad de certificación raíz a nivel de SO, pero un navegador web en ese servidor podría no hacerlo ya que mantiene su propia base de datos

El servidor en el que estoy trabajando ya ha generado los siguientes archivos: server.crt y server.key . Creo que estos se generan utilizando openssl genrsa . Entiendo que el .crt es el certificado público y el .key es su contraparte de clave privada. Mi pregunta principal es

  1. ¿El otro servidor puede tratar el .crt como un certificado a nivel de marco o una Autoridad de certificación raíz a nivel del sistema operativo (es decir, puedo elegir cómo instalarlo)? En mi investigación en línea, esto ha sido muy confuso ya que muchos de los términos parecen sobrecargados. No puedo saber si estoy trabajando con una Autoridad de certificación o solo con un certificado regular.
  2. Si la respuesta a 1 es no, ¿qué tipo de archivo necesito generar a partir de los archivos existentes para instalar solo el certificado autofirmado?

Cualquier ayuda es muy apreciada, y supongamos que proporcionar enlaces a páginas de Wikipedia no me ayudará mucho.

    
pregunta tomfumb 03.03.2015 - 04:16
fuente

4 respuestas

9

Debería ver la infraestructura del certificado (es decir, la PKI, Public Key Infrastructur) como una red de confianza.

Cuando se está comunicando con varias personas, lo que quiere autenticarse mutuamente (y sus sitios web), primero elige una persona de confianza común. Esta tercera persona se convierte en una "Tercera parte de confianza" y se llamará "Autoridad de certificación" (CA) con el propósito de gestionar el certificado.

La CA creará una clave maestra, también conocida como clave de CA raíz. La clave privada se mantendrá en secreto por el TTP a toda costa. La clave pública se integrará en un certificado y este certificado estará firmado por la clave pública de la CA. Esto significa que el certificado es autofirmado y puede verificar la firma con la clave en su interior.

Supongamos ahora que quieres acceder al sitio web de Alice, pero quieres que sea realmente el sitio web de Alice y no otra persona que diga ser ella. Alice es parte de tu comunidad y, por lo tanto, se pone en contacto con la CA que aceptaste usar. Ella envía a la CA una CSR (solicitud de firma de certificado) que básicamente es una clave pública. La AC realiza el proceso de verificación de que Alice es Alice (por ejemplo, la persona responsable se encuentra con Alice en persona y obtiene el CSR de sus manos). Cuando la CA está segura de que Alice es Alice y la CSR le pertenece, la CA puede crear un certificado con el nombre de Alice y firmar este certificado con la clave privada de la CA.

Cuando te conectas en el sitio web de Alice, pides el certificado. Una vez que obtenga el certificado, desea verificar que sea el correcto. Puede ver en el certificado que ha sido emitido por una CA. Si tienes la clave CA puedes verificar la firma. Si confía en que la CA está haciendo su trabajo correctamente, entonces puede confiar en que este certificado es bueno y como la CA confía en que autentificó a Alice en primer lugar, entonces puede confiar en que este certificado pertenece a Alice.

Luego puede estar seguro de que el cifrado de un mensaje con esta clave pública solo será leído por Alicia que tenga la clave privada correspondiente. También está seguro de que todo lo que se cite mediante este certificado es una firma hecha por Alice.

Si Alice quiere autenticarte a cambio, entonces debes hacer lo mismo (obtener un certificado firmado por la CA, ya que Alice confía en la CA y también confiará en este certificado)

En su caso, dado que parece que domina todos los puntos finales, simplemente podría crear dos certificados autofirmados (que en realidad son dos certificados de CA raíz) e intercambiar las partes públicas al otro punto final. Cada punto final utilizará su propia clave privada para firmar solicitudes salientes y descifrar los mensajes entrantes, y el otro certificado de punto final para cifrar los mensajes salientes y verificar los mensajes entrantes.

Si tiene muchos puntos finales, podría valer la pena crear su propia CA. Genera un certificado de CA raíz y, a continuación, firma el certificado para cada punto final. En cada punto final puede instalar el certificado de CA raíz público. Luego, cada vez que un punto final se conecta a otro, el punto final contactado puede enviar su certificado y la persona que llama puede verificarlo con el certificado de CA raíz.

El primer método tiene la ventaja de ser sencillo, pero comprometer un certificado implica cambiarlo por uno nuevo en todos los puntos finales. El segundo método tiene la ventaja de ser escalable, un punto final no tiene que saber cuántos otros puntos finales existe, ya que puede validar el certificado sobre la marcha de todos modos. Además, hay una manera de gestionar el compromiso clave con las listas de revocación de certificados, por ejemplo.

    
respondido por el M'vy 03.03.2015 - 09:59
fuente
1

Las dos opciones que mencionas son casi correctas: Sin embargo, puedes (y deberías) instalar certificados autofirmados sin que sean certificados de Autoridad de Certificación.

La diferencia entre un certificado autofirmado y un certificado CA es que un certificado CA es un certificado autofirmado especial con sus "BasicConstraints" establecidas en "CA: true" (generalmente con el conjunto de indicadores críticos). Además, la secuencia de uso de claves del certificado de CA enumera "cRLSign" y "keyCertSign" como propósitos que no deben presentarse en un certificado regular (no CA).

Ahora a tus dos preguntas:

  1. Puede usarlo como un certificado a nivel de marco o de sistema operativo a su gusto, pero no confunda los certificados autofirmados con los certificados de CA (consulte más arriba). Como el certificado parece ser un certificado de propósito especial solo para su aplicación, recomendaría usarlo como certificado de nivel de marco. Además, la instalación de un certificado de nivel de SO confiable puede requerir privilegios de administrador que no todos los socios de comunicación pueden tener.

  2. N / A (dado que la respuesta a 1. es sí :))

En una nota al margen: la razón por la cual la distinción entre certificados autofirmados de CA y no CA es relevante es que no debe permitir que un certificado autofirmado, cuyo propósito es validar un socio de comunicación, actúe como un certificado autoridad ya que esto podría generar implicaciones de seguridad adicionales (es decir, ataques MITM que usan dicho certificado como autoridad confiable).

    
respondido por el Alexander Stumpf 20.04.2016 - 11:46
fuente
0

Aquí está intentando autenticar y confiar en ambas redes mientras actúa como bidireccional. El certificado de autoridad de confianza es diferente / igual y el certificado de emisión de CA puede ser diferente o el mismo sobre el que no tiene ningún problema.

Nota: no utilice certificados autofirmados para las comunicaciones SSL y siga las reglas estándar de RFC.

Si desea establecer comunicación entre dos redes, hay varias formas. 1) Establecimiento de túneles 2) PTP 3) basado en SSL:        a. Simplemente cree dos CA diferentes y colóquelas en las redes y cada certificado de CA se colocará con cada red. Ahora cada CA debe emitir el certificado y será validada por la confianza y la comunicación será más segura ahora.

    
respondido por el user45475 03.03.2015 - 04:39
fuente
0

Lo que la aplicación debe hacer después de configurar la conexión es verificar la validez del certificado recibido. Podrías hacer esto con un guiño a pki, es decir.

  1. tiene certificados CA en la aplicación que pueden verificar el emisor del certificado recibido

o

  1. Un emisor del certificado recibido, es decir, el mismo.

Mucho de esto depende de si estás rodando tu propia biblioteca o dependiendo de una API.

    
respondido por el munchkin 03.03.2015 - 06:57
fuente

Lea otras preguntas en las etiquetas