Trust Store vs Key Store: creación con keytool


249

Entiendo que el almacén de claves generalmente contendría claves privadas / públicas y el almacén de confianza solo las claves públicas (y representa la lista de partes de confianza con las que tiene la intención de comunicarse). Bueno, esa es mi primera suposición, así que si eso no es correcto, probablemente no haya comenzado muy bien ...

Sin embargo, estaba interesado en comprender cómo / cuándo distingue las tiendas cuando usa keytool.

Entonces, hasta ahora he creado un almacén de claves usando

keytool -import -alias bob -file bob.crt -keystore keystore.ks

que crea mi archivo keystore.ks. Respondo yesa la pregunta ¿Confío en Bob pero no me queda claro si esto ha creado un archivo de almacén de claves o un archivo de almacén de confianza? Puedo configurar mi aplicación para usar el archivo como cualquiera.

-Djavax.net.ssl.keyStore=keystore.ks -Djavax.net.ssl.keyStorePassword=x
-Djavax.net.ssl.trustStore=keystore.ks -Djavax.net.ssl.trustStorePassword=x

y con System.setProperty( "javax.net.debug", "ssl")set, puedo ver el certificado en certificaciones de confianza (pero no en la sección del almacén de claves). El certificado particular que estoy importando solo tiene una clave pública y tengo la intención de usarlo para enviar cosas a través de una conexión SSL a Bob (¡pero tal vez sea mejor dejarlo para otra pregunta!).

Cualquier sugerencia o aclaración sería muy apreciada. ¿La salida de keytool es la misma que importa y es solo una convención que dice que uno es un almacén de claves y el otro un almacén de confianza? ¿Cuál es la relación cuando se usa SSL, etc.?


No estoy seguro de lo que quiere decir con "El certificado particular que estoy importando solo tiene una clave pública": ¿es solo una clave pública (es decir, no un certificado) o un certificado que no es CA?
Bruno

hmmm, no estoy seguro. Exporté desde mi navegador como un archivo PEM. ¿Eso ayuda?
Toby

Si se exporta desde el navegador, probablemente sea un certificado. ¿Es un certificado de servidor (con un CN o subjectAltName que coincida con el nombre de un servidor)? ¿Es un certificado de CA? (Mira en Restricciones básicas, deberías poder ver esto usando tu navegador).
Bruno

2
tl; dr: los almacenes de confianza contienen certificados públicos, de confianza, raíz (CA), mientras que los almacenes de identidad / clave contienen certificados de identidad privados; en cuanto a archivos, sin embargo, son lo mismo.
Andrew

Respuestas:


346

La terminología es un poco confusa, pero ambas javax.net.ssl.keyStorey javax.net.ssl.trustStorese usan para especificar qué almacenes de claves usar, para dos propósitos diferentes. Los almacenes de claves vienen en varios formatos y ni siquiera son necesariamente archivos (vea esta pregunta ), y keytooles solo una herramienta para realizar varias operaciones en ellos (importar / exportar / lista / ...).

Los parámetros javax.net.ssl.keyStorey javax.net.ssl.trustStoreson los parámetros predeterminados que se usan para construir KeyManagers y TrustManagers (respectivamente), y luego se usan para construir uno SSLContextque esencialmente contiene la configuración SSL / TLS para usar cuando se realiza una conexión SSL / TLS a través de an SSLSocketFactoryo an SSLEngine. Estas propiedades del sistema son exactamente de donde provienen los valores predeterminados, que luego son utilizados por ellos SSLContext.getDefault()mismos, por SSLSocketFactory.getDefault()ejemplo. (Todo esto se puede personalizar a través de la API en varios lugares, si no desea utilizar los valores predeterminados y los específicos SSLContextpara un propósito determinado).

La diferencia entre KeyManagery TrustManager(y, por lo tanto, entre javax.net.ssl.keyStorey javax.net.ssl.trustStore) es la siguiente (citado de la guía de referencia JSSE ):

TrustManager: determina si las credenciales de autenticación remota (y, por lo tanto, la conexión) deben ser confiables.

KeyManager: determina qué credenciales de autenticación se deben enviar al host remoto.

(Hay otros parámetros disponibles y sus valores predeterminados se describen en la guía de referencia de JSSE . Tenga en cuenta que si bien hay un valor predeterminado para el almacén de confianza, no hay uno para el almacén de claves).

Esencialmente, el almacén de claves javax.net.ssl.keyStoreestá destinado a contener sus claves privadas y certificados, mientras que javax.net.ssl.trustStoreestá destinado a contener los certificados de CA en los que está dispuesto a confiar cuando una parte remota presenta su certificado. En algunos casos, pueden ser una sola tienda, aunque a menudo es una mejor práctica usar tiendas distintas (especialmente cuando están basadas en archivos).


gracias por la respuesta, aclara un poco las cosas. Sin embargo, todavía estoy confundido cuando se trata de uso, puedo usar una clave pk12 pri / pub (xxx.p12) como un almacén de claves (a través de -D) y crear una conexión SSL (confiable) sin ninguna mención de un almacén de confianza a través de - D ... oh bien.
Toby

57
No necesita especificar un almacén de confianza, porque hay un valor predeterminado para él (está incluido con el JRE), generalmente en $JAVA_HOME/lib/security/cacerts(consulte el enlace de la segunda guía de referencia JSSE que envié). Al igual que los navegadores, contiene un conjunto predeterminado de certificados de CA confiables. En general, un cliente siempre usará un almacén de confianza para verificar el certificado del servidor, pero el almacén de claves solo se usará si el servidor solicita un certificado de cliente, y el servidor siempre usará un almacén de claves para su propia clave + cert, pero el almacén de confianza solo será se usa si el cliente envía un certificado de cliente.
Bruno

2
Gracias por la información útil. En Weblogic, hay un "almacén de claves de identidad" que almacena el certificado SSL del servidor y luego hay un "almacén de claves de confianza" que almacena los certificados SSL en los que el servidor confía, así que estoy en lo correcto si digo que "clave de identidad -store "no es más que un" almacén de claves "y" trust-key-store "no es más que un" almacén de confianza "?
hagrawal

@Bruno también debemos tener en cuenta que cuando hay un "jssecacerts", se ignora "cacerts"?
kommradHomer

61

Para explicar de manera común el caso de uso / propósito o laico:

TrustStore : como su nombre indica, normalmente se usa para almacenar los certificados de entidades de confianza. Un proceso puede mantener un almacén de certificados de todas sus partes de confianza en las que confía.

keyStore : se utiliza para almacenar las claves del servidor (tanto públicas como privadas) junto con el certificado firmado.

Durante el protocolo de enlace SSL,

  1. Un cliente intenta acceder a https: //

  2. Y por lo tanto, el servidor responde proporcionando un certificado SSL (que se almacena en su almacén de claves)

  3. Ahora, el cliente recibe el certificado SSL y lo verifica a través de trustStore (es decir, el trustStore del cliente ya tiene un conjunto predefinido de certificados en los que confía). Es como: ¿Puedo confiar en este servidor? ¿Es este el mismo servidor con el que estoy tratando de hablar? ¿No hay ataques de intermediarios?

  4. Una vez, el cliente verifica que está hablando con el servidor en el que confía, entonces la comunicación SSL puede ocurrir a través de una clave secreta compartida.

Nota: No estoy hablando aquí sobre la autenticación del cliente en el lado del servidor. Si un servidor también quiere hacer una autenticación de cliente, entonces el servidor también mantiene un TrustStore para verificar el cliente.


25

No hay diferencia entre el almacén de claves y los archivos del almacén de confianza. Ambos son archivos en el formato de archivo JKS patentado. La distinción está en el uso: que yo sepa, Java solo usará el almacén al que hace referencia la -Djavax.net.ssl.trustStorepropiedad del sistema para buscar certificados de confianza al crear conexiones SSL. Lo mismo para las llaves y -Djavax.net.ssl.keyStore. Pero, en teoría, está bien usar el mismo archivo para almacenes de confianza y claves.


44
Se pueden utilizar diferentes tipos de almacén de claves (por ejemplo, PKCS12) mediante el establecimiento de los javax.net.ssl.keyStoreTypey javax.net.ssl.trustStoreTypelas propiedades del sistema.
Donal Fellows

1
@Donal: Buena adición. ¿Sabes si hay una lista de todos los contenedores compatibles? Solo sé de PKCS12 y JKS (el primero es el resultado de prueba y error ...).
musiKk

2
los formatos del almacén de claves varían según los proveedores disponibles (consulte esta lista para aquellos incluidos con Oracle JRE de forma predeterminada). También hubo una discusión en esta pregunta . Otros proveedores (por ejemplo, BouncyCastle) se pueden usar para otros formatos.
Bruno

21

Keystore es utilizado por un servidor para almacenar claves privadas, y Truststore es utilizado por un cliente externo para almacenar claves públicas proporcionadas por el servidor para acceder. Lo he hecho en mi aplicación de producción. A continuación se detallan los pasos para generar certificados java para la comunicación SSL:

  1. Genere un certificado usando el comando keygen en Windows:

keytool -genkey -keystore server.keystore -alias mycert -keyalg RSA -keysize 2048 -validity 3950

  1. Autocertificar el certificado:

keytool -selfcert -alias mycert -keystore server.keystore -validity 3950

  1. Exportar certificado a la carpeta:

keytool -export -alias mycert -keystore server.keystore -rfc -file mycert.cer

  1. Importar certificado en el almacén de confianza del cliente:

keytool -importcert -alias mycert -file mycert.cer -keystore truststore


Hola, tengo un escenario en el que tengo dos aplicaciones diferentes dentro del mismo contenedor (tomcat). Desde ambas aplicaciones, tengo que llamar a los puntos finales de descanso de ambos lados para cada aplicación. Como, de A a B y de B a A (A y B son las dos aplicaciones). ¿Necesito usar el almacén de confianza en este escenario? Como estoy usando el cliente de descanso personalizado que está usando el almacén de claves. Por favor recomiende.
Deepak

0

Estos son los pasos para crear un Truststore en su máquina local usando Keytool. Pasos para crear un almacén de confianza para una URL en su máquina local.

1) Presione la URL en el navegador usando Chrome

2) Verifique el ícono "i" a la izquierda de la url en Chrome y haga clic en él

3) Verifique la opción de certificado y haga clic en él y se abrirá un cuadro de diálogo

4) verifique la pestaña "ruta del certificado" para ver la cantidad de certificados disponibles para crear el almacén de confianza

5) Vaya el "details" tab -> click"Copy to File" -> Give the path and the name for the certificateque desea crear.

6) Verifique si tiene certificados principales y siga el punto "5" .

7) Después de crear todos los certificados, abra el símbolo del sistema y navegue hasta la ruta donde creó los certificados.

8) proporcione el siguiente comando Keytool para agregar los certificados y crear un almacén de confianza.

Sample: 
   keytool -import -alias abcdefg -file abcdefg.cer -keystore cacerts
        where "abcdefg" is the alias name and "abcdefg.cer" is the actual certificate name and "cacerts" is the truststore name

9) Proporcione el comando keytool para todos los certificados y agréguelos al almacén de confianza.

    keytool -list -v -keystore cacerts

-1

keystore simplemente almacena claves privadas, mientras que truststore almacena claves públicas. Deberá generar un certificado Java para la comunicación SSL. Puede usar un comando keygen en Windows, esta será probablemente la solución más fácil.


Un almacén de confianza almacena certificados de
Marqués de Lorne

-1

En términos más simples:

Keystore se usa para almacenar su credencial (servidor o cliente) mientras que truststore se usa para almacenar otras credenciales (Certificados de CA).

El almacén de claves es necesario cuando configura el lado del servidor en SSL, se usa para almacenar el certificado de identidad del servidor, qué servidor presentará a un cliente en la conexión, mientras que la configuración del almacén de confianza en el lado del cliente debe contener para que la conexión funcione. Si su navegador se conecta a cualquier sitio web a través de SSL, verifica el certificado presentado por el servidor contra su almacén de confianza.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.