OpenSSL y s_client: ¿por qué se requiere una clave privada del cliente?

Question

Necesito configurar un canal de comunicación SSL de 2 vías entre una aplicación .NET/WCF y un servidor web de terceros. En este momento estoy intentando obtener un apretón de manos exitoso con el host para validar que todos los elementos estén configurados correctamente (certificado de cliente, autoridad de certificación de servidor, comunicación de red ...). Estoy usando la herramienta de línea de comandos de openSSL para probar y validar esto, usando el comando s_client.

Aquí es lo que me está parando, y lo que no puede entender:

• lo que haga, openSSL espera encontrar una clave privada del certificado cliente
• el certificado de cliente me fue dada por el tercero, pero no contiene ninguna clave privada
• si acabo de generar mi propio archivo de clave privada usando openSSL, estoy recibiendo unos valores clave falta de coincidencia de error

Tenga en cuenta que acabo de comenzar a poner mis manos en SSL, así que tengo una comprensión muy básica de todo el protocolo. Por lo que he estado leyendo, parece que tanto el servidor como el cliente necesitan su clave privada en una configuración SSL de 2 vías. Sin embargo, no puedo encontrar la manera de obtener una clave privada que funcione en mi cliente (trabajando con el certificado del cliente que me fue entregado). Agradecería mucho que alguien pudiera arrojar algo de luz sobre las claves privadas del certificado del cliente, ya que esto me está causando un gran dolor de cabeza.

Gracias!

Answer 1

Los certificados en sí mismos son solo datos públicos. Lo que vincula un certificado de clave pública con el nombre que contiene es el hecho de que quien tenga control legítimo sobre ese nombre (por ejemplo, su nombre o el nombre de su servidor) también tiene la clave privada para ello.

Los certificados se utilizan para probar la identidad de la ubicación remota al desafiar a la ubicación remota a realizar una operación que solo se puede hacer con la clave privada correspondiente: firmar algo (que se puede verificar con la clave pública) o descifrar algo eso fue encriptado con la clave pública. (Ambos pueden suceder en el protocolo de enlace SSL/TLS, dependiendo del conjunto de cifrado).

Durante el protocolo de enlace SSL/TLS, el servidor envía su certificado (en claro) y prueba al cliente que tiene la clave privada correspondiente using an authenticated key exchange.

En su caso, también desea utilizar la autenticación de certificado de cliente. No es suficiente enviar el certificado del cliente durante el protocolo de enlace: el cliente también debe demostrar que tiene la clave privada. De lo contrario, cualquiera que reciba ese certificado podría clonarlo. El objetivo de usar certificados es evitar cualquier clonación, de modo que nunca tenga que mostrar su propio secreto (la clave privada).

Más específicamente, el cliente debe firmar los mensajes de saludo en el mensaje Certificate Verify del saludo de TLS para que el servidor pueda verificarlo contra la clave pública enviada en el certificado del cliente. Sin este paso, no se llevaría a cabo ninguna autenticación de certificado de cliente .

se le dio el certificado de cliente para mí por el tercero, pero sí no contiene ninguna clave privada

Dándole su certificado sin su clave privada parece un poco inútil, a menos que esté se espera que haya generado una solicitud de certificado de su parte de antemano (en cuyo caso usted tendría la clave privada).

De hecho, en lugar de recibir un certificado y su clave privada, es mejor que genere su par de claves, cree una solicitud de certificado (CSR) y solicite a su CA un certificado de esa CSR (pero sin ellos siempre sabiendo su clave privada). En este caso, se espera que haya conservado su clave privada, y podrá utilizarla con el certificado que hubiera recibido.