Trust Store vs Key Store - création avec keytool


249

Je comprends que le magasin de clés détiendrait généralement des clés privées / publiques et le magasin de clés de confiance uniquement des clés publiques (et représente la liste des parties de confiance avec lesquelles vous avez l'intention de communiquer). Eh bien, c'est ma première hypothèse, donc si ce n'est pas correct, je n'ai probablement pas très bien commencé ...

J'étais cependant intéressé à comprendre comment / quand vous distinguez les magasins lors de l'utilisation de keytool.

Donc, jusqu'à présent, j'ai créé un magasin de clés en utilisant

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

qui crée mon fichier keystore.ks. Je réponds yesà la question est-ce que je fais confiance à bob mais je ne sais pas si cela a créé un fichier keystore ou un fichier truststore? Je peux configurer mon application pour utiliser le fichier comme l'un ou l'autre.

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

et avec l' System.setProperty( "javax.net.debug", "ssl")ensemble, je peux voir le certificat sous des certifications de confiance (mais pas sous la section keystore). Le certificat particulier que j'importe n'a qu'une clé publique et j'ai l'intention de l'utiliser pour envoyer des trucs via une connexion SSL à Bob (mais il vaut peut-être mieux laisser une autre question!).

Toute indication ou clarification serait très appréciée. La sortie de keytool est-elle la même que vous importiez et sa juste convention qui dit que l'un est un magasin de clés et l'autre un magasin de confiance? Quelle est la relation lors de l'utilisation de SSL, etc.?


Je ne sais pas ce que vous entendez par "le certificat particulier que j'importe n'a qu'une clé publique": est-ce juste une clé publique (c'est-à-dire pas un certificat) ou un certificat non-CA?
Bruno

hmmm, pas sûr. J'ai exporté depuis mon navigateur sous forme de fichier PEM. Est ce que ça aide?
Toby

S'il est exporté depuis le navigateur, c'est probablement un certificat. S'agit-il d'un certificat de serveur (avec un CN ou subjectAltName correspondant au nom d'un serveur)? S'agit-il d'un certificat CA (regardez sous Contraintes de base, vous devriez pouvoir le voir à l'aide de votre navigateur).
Bruno

2
tl; dr: les magasins de clés de confiance contiennent des certificats racine (CA) publics, alors que les magasins de clés / identités contiennent des certificats d'identité privés; au niveau des fichiers, cependant, ce sont les mêmes.
Andrew

Réponses:


346

La terminologie est un peu déroutante en effet, mais les deux javax.net.ssl.keyStoreet javax.net.ssl.trustStoresont utilisés pour spécifier les fichiers de clés à utiliser, à deux fins différentes. Les magasins de clés se présentent sous différents formats et ne sont même pas nécessairement des fichiers (voir cette question ), et ne keytoolsont qu'un outil pour effectuer diverses opérations sur eux (import / export / list / ...).

Les paramètres javax.net.ssl.keyStoreet javax.net.ssl.trustStoresont les paramètres par défaut utilisés pour créer KeyManagers et TrustManagers (respectivement), puis utilisés pour créer un SSLContextqui contient essentiellement les paramètres SSL / TLS à utiliser lors de l'établissement d'une connexion SSL / TLS via un SSLSocketFactoryou un SSLEngine. Ces propriétés système sont exactement d'où proviennent les valeurs par défaut, qui sont ensuite utilisées par SSLContext.getDefault(), elle-même utilisée par SSLSocketFactory.getDefault()exemple. (Tout cela peut être personnalisé via l'API à plusieurs endroits, si vous ne souhaitez pas utiliser les valeurs par défaut etSSLContext pour un objectif donné.)

La différence entre le KeyManageret TrustManager(et donc entre javax.net.ssl.keyStoreet javax.net.ssl.trustStore) est la suivante (citée dans le guide de référence JSSE ):

TrustManager: détermine si les informations d'authentification à distance (et donc la connexion) doivent être approuvées.

KeyManager: détermine les informations d'authentification à envoyer à l'hôte distant.

(D'autres paramètres sont disponibles et leurs valeurs par défaut sont décrites dans le guide de référence JSSE . Notez que s'il existe une valeur par défaut pour le magasin de clés de confiance, il n'y en a pas pour le magasin de clés.)

Essentiellement, le magasin de javax.net.ssl.keyStoreclés est destiné à contenir vos clés et certificats privés, tandis que le javax.net.ssl.trustStoreest destiné à contenir les certificats d'autorité de certification auxquels vous êtes prêt à faire confiance lorsqu'une partie distante présente son certificat. Dans certains cas, ils peuvent être un seul et même magasin, bien qu'il soit souvent préférable d'utiliser des magasins distincts (en particulier lorsqu'ils sont basés sur des fichiers).


merci pour la réponse, ça clarifie un peu les choses. Je suis toujours confus en ce qui concerne l'utilisation, je peux utiliser une clé pk12 pri / pub (xxx.p12) comme magasin de clés (via -D) et créer une connexion SSL (de confiance) sans aucune mention d'un magasin de confiance via - D ... eh bien.
Toby

57
Vous n'avez pas besoin de spécifier un fichier de clés de confiance, car il y a une valeur par défaut (il est fourni avec le JRE), généralement dans $JAVA_HOME/lib/security/cacerts(voir le deuxième lien du guide de référence JSSE que j'ai envoyé). Comme les navigateurs, il contient un ensemble par défaut de certificats CA de confiance. En général, un client utilisera toujours un fichier de clés certifiées pour vérifier le certificat du serveur, mais le fichier de clés ne sera utilisé que si le serveur demande un certificat client, et le serveur utilisera toujours un fichier de clés pour sa propre clé + certificat, mais le fichier de clés de confiance ne sera utilisé si le client envoie un certificat client.
Bruno

2
Merci pour les informations utiles. Dans Weblogic, il y a "magasin de clés d'identité" qui stocke le certificat SSL du serveur et puis il y a "magasin de clés de confiance" qui stocke les certificats SSL auxquels le serveur fait confiance, donc ai-je raison de dire que "clé d'identité" -store "n'est rien d'autre qu'un" keystore "et" trust-key-store "n'est rien d'autre qu'un" truststore "?
hagrawal

@Bruno doit également noter que lorsqu'il y a un "jssecacerts", "cacerts" est ignoré?
kommradHomer

61

Pour expliquer de manière usuelle / but commun ou de manière profane:

TrustStore : comme son nom l'indique, il est normalement utilisé pour stocker les certificats des entités de confiance. Un processus peut conserver une banque de certificats de toutes ses parties de confiance auxquelles il fait confiance.

keyStore : utilisé pour stocker les clés du serveur (publiques et privées) avec le certificat signé.

Pendant la prise de contact SSL,

  1. Un client essaie d'accéder à https: //

  2. Et ainsi, le serveur répond en fournissant un certificat SSL (qui est stocké dans son magasin de clés)

  3. Maintenant, le client reçoit le certificat SSL et le vérifie via trustStore (c'est-à-dire que le trustStore du client a déjà un ensemble prédéfini de certificats auquel il fait confiance). Son genre: puis-je faire confiance à ce serveur? Est-ce le même serveur auquel j'essaie de parler? Pas d'attaques intermédiaires?

  4. Une fois, le client vérifie qu'il parle au serveur auquel il fait confiance, la communication SSL peut alors se faire via une clé secrète partagée.

Remarque: je ne parle pas ici de l'authentification client côté serveur. Si un serveur souhaite également effectuer une authentification client, le serveur gère également un trustStore pour vérifier le client.


25

Il n'y a aucune différence entre les fichiers de clés et les fichiers de clés certifiées. Les deux sont des fichiers au format de fichier JKS propriétaire. La distinction est dans l'utilisation: à ma connaissance, Java n'utilisera que le magasin référencé par la -Djavax.net.ssl.trustStorepropriété système pour rechercher des certificats de confiance lors de la création de connexions SSL. Idem pour les clés et -Djavax.net.ssl.keyStore. Mais en théorie, il est bon d'utiliser un seul et même fichier pour les fichiers de clés de confiance et.


4
Vous pouvez utiliser différents types de fichier de clés (par exemple, PKCS12) en définissant les propriétés système javax.net.ssl.keyStoreTypeet javax.net.ssl.trustStoreType.
Donal Fellows

1
@Donal: Bon ajout. Savez-vous par hasard s'il existe une liste de tous les conteneurs pris en charge? Je ne connais que PKCS12 et JKS (le premier étant le résultat d'essais et d'erreurs ...).
musiKk

2
les formats de fichier de clés varient en fonction des fournisseurs disponibles (consultez cette liste pour ceux fournis avec Oracle JRE par défaut). Il y a également eu une discussion sur cette question . D'autres fournisseurs (par exemple BouncyCastle) peuvent être utilisés pour d'autres formats.
Bruno

21

Le magasin de clés est utilisé par un serveur pour stocker les clés privées et Truststore est utilisé par un client tiers pour stocker les clés publiques fournies par le serveur pour y accéder. Je l'ai fait dans ma demande de production. Voici les étapes pour générer des certificats java pour la communication SSL:

  1. Générez un certificat en utilisant la commande keygen dans Windows:

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

  1. Autocertifiez le certificat:

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

  1. Exporter le certificat dans un dossier:

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

  1. Importer un certificat dans le Truststore client:

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


Salut, j'ai un scénario où j'ai deux applications différentes dans le même conteneur (tomcat). À partir des deux applications, je dois appeler les points de terminaison restants des deux côtés à chaque application. Comme, de A à B et B à A (A et B sont les deux applications). Dois-je utiliser le magasin de clés de confiance dans ce scénario? Comme j'utilise un client de repos personnalisé qui utilise un magasin de clés. Veuillez suggérer.
Deepak

0

Ce sont les étapes pour créer un Truststore sur votre machine locale à l'aide de Keytool. Étapes pour créer un fichier de clés de confiance pour une URL dans votre ordinateur local.

1) Frappez l'url dans le navigateur en utilisant Chrome

2) Vérifiez le "i" icône à gauche de l'url dans le chrome et cliquez dessus

3) Vérifiez l' option de certificat et cliquez dessus et une boîte de dialogue s'ouvrira

4) vérifiez l' onglet "chemin du certificat" pour le nombre de certificats disponibles pour créer le truststore

5) Allez "details" tab -> click"Copy to File" -> Give the path and the name for the certificate vous souhaitez créer.

6) Vérifiez s'il a des certificats parents et suivez le point "5" .

7) Une fois tous les certificats créés, ouvrez l'invite de commande et accédez au chemin d'accès où vous avez créé les certificats.

8) fournissez la commande Keytool ci-dessous pour ajouter les certificats et créer un fichier de clés certifiées.

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) Fournissez la commande keytool pour tous les certificats et ajoutez-les au magasin de clés de confiance.

    keytool -list -v -keystore cacerts

-1

keystore stocke simplement les clés privées, tandis que truststore stocke les clés publiques. Vous souhaiterez générer un certificat java pour la communication SSL. Vous pouvez utiliser une commande keygen dans Windows, ce sera probablement la solution la plus simple.


Un magasin de confiance stocke les certificats de
Marquis de Lorne

-1

En termes simples:

Keystore est utilisé pour stocker vos informations d'identification (serveur ou client) tandis que truststore est utilisé pour stocker d'autres informations d'identification (certificats de CA).

Le magasin de clés est nécessaire lorsque vous configurez côté serveur sur SSL, il est utilisé pour stocker le certificat d'identité du serveur, que le serveur présentera à un client lors de la connexion tandis que la configuration du magasin de clés de confiance côté client doit contenir pour que la connexion fonctionne. Si votre navigateur se connecte à un site Web via SSL, il vérifie le certificat présenté par le serveur par rapport à son magasin de confiance.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.