Pregunta:
Espero que alguien pueda ayudarme a comprender algunos conceptos básicos sobre 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 cliente y servidor en la comunicación bidireccional. Utilizarán servicios REST a través de HTTPS con el firewall de cada red abierto explícitamente para la otra. Todos los certificados SSL serán autofirmados. Mi aplicación está escrita en Java pero no estoy seguro de la otra.
Creo que tengo dos opciones para establecer las conexiones HTTPS con certificados autofirmados:
- 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 sistema operativo más amplio, que confía en el certificado
- Cada servidor instala el certificado del otro como una autoridad certificadora 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 sistema operativo, pero un navegador web en ese servidor podría no reconocerlo, ya que mantiene su propia base de datos.
El servidor en el que estoy trabajando ya tiene los siguientes archivos generados: server.crt y server.key . Creo que estos se generan usando openssl genrsa . Entiendo que .crt es el certificado público y .key es su contraparte de clave privada. Mi pregunta principal es
- ¿El
.crtpuede ser tratado como un certificado de nivel de marco o una Autoridad de Certificación raíz de nivel de sistema operativo por el otro servidor (es decir, puedo elegir cómo lo instalo)? En mi investigación en línea, esto ha sido muy confuso ya que muchos de los términos parecen sobrecargados. No sé si estoy trabajando con una autoridad de certificación o solo con un certificado normal. - 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?
Se agradece mucho cualquier ayuda y, por favor, asuma que proporcionar enlaces a las páginas de Wikipedia no me ayudará mucho.
Respuesta:
Debería ver la infraestructura de certificados (es decir, la PKI, Public Key Infrastructur) como una red de confianza.
Cuando se comunica con varias personas que desean autenticarse mutuamente (y sus sitios web), primero elige una persona de confianza común. Esta tercera persona se convierte en un "Tercero de confianza" y se denominará "Autoridad de certificación" (CA) a los efectos de la gestión de certificados.
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 incrustará en un certificado y este certificado estará firmado por la clave pública de la CA. Esto significa que el certificado está autofirmado y puede verificar la firma con la clave dentro.
Supongamos ahora que quiere acceder al sitio web de Alice, pero quiere que sea realmente el sitio web de Alice y no otra persona que dice ser ella. Alice es parte de su comunidad y, por lo tanto, se comunica con la CA que acordó utilizar. Ella envía a la CA una CSR (Solicitud de firma de certificado) que básicamente es una clave pública. El CA realiza el proceso de verificar 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 a nombre de Alice y firmar este certificado con la clave privada de la CA.
Cuando se conecta al sitio web de Alice, solicita el certificado. Una vez que obtenga el certificado, querrá verificar que sea el correcto. Puede ver en el certificado que ha sido emitido por una CA. Si tiene la clave CA, puede 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, dado que la CA confía en que autenticó a Alice en primer lugar, puede confiar en que este certificado pertenece a Alice.
Entonces puede estar seguro de que el cifrado de un mensaje con esta clave pública solo será leído por Alice, quien tiene la clave privada correspondiente. También está seguro de que todo lo que este certificado haya firmado es una firma de Alice.
Si Alice quiere autenticarte a cambio, entonces debes hacer lo mismo (obtener un certificado firmado por la CA, ya que Alice también confía en la CA, ella también confiará en este certificado)
En su caso, dado que parece que domina todos los puntos finales, podría simplemente crear dos certificados autofirmados (que de hecho son dos certificados de CA raíz) e intercambiar las partes públicas por el 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 el mensaje saliente 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 luego firma el certificado para cada punto final. En cada punto final, puede instalar el certificado de CA raíz pública. 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 raíz-CA.
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 existen, ya que puede validar el certificado sobre la marcha de todos modos. Además, existe una forma de gestionar el compromiso de claves con Listas de revocación de certificados, por ejemplo.