Je comprends que le fichier de clés contient généralement des clés privées/publiques et que le magasin de clés de confiance ne stocke que 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é ...
Je voulais savoir comment et quand distinguer les magasins lors de l’utilisation de keytool.
Donc, jusqu'ici, j'ai créé un magasin de clés en utilisant
keytool -import -alias bob -file bob.crt -keystore keystore.ks
ce qui crée mon fichier keystore.ks. Je réponds yes
à la question si je fais confiance à Bob, mais il m'est difficile de savoir si cela a créé un fichier de clés ou un fichier de magasin de clés de confiance. Je peux configurer mon application pour utiliser le fichier comme tel.
-Djavax.net.ssl.keyStore=keystore.ks -Djavax.net.ssl.keyStorePassword=x
-Djavax.net.ssl.trustStore=keystore.ks -Djavax.net.ssl.trustStorePassword=x
et avec System.setProperty( "javax.net.debug", "ssl")
set, je peux voir le certificat sous des certifications de confiance (mais pas dans la section keystore). Le certificat que je suis en train d'importer n'a qu'une clé publique et j'ai l'intention de l'utiliser pour envoyer des éléments 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 identique à celle que vous importez et selon sa convention qui dit que l’un est un magasin de clés et que l’autre est un magasin de confiance? Quelle est la relation lors de l'utilisation de SSL, etc.?
La terminologie est un peu déroutante, mais javax.net.ssl.keyStore
et javax.net.ssl.trustStore
sont utilisés pour spécifier les magasins de clés à utiliser, à des fins différentes. Les magasins de clés sont disponibles dans différents formats et ne sont même pas nécessairement des fichiers (voir cette question ), et keytool
n’est qu’un outil permettant d’exécuter diverses opérations sur ceux-ci (import/export/list/... ).
Les paramètres javax.net.ssl.keyStore
et javax.net.ssl.trustStore
sont les paramètres par défaut utilisés pour construire KeyManager
s et TrustManager
s (respectivement), puis utilisés pour créer un SSLContext
contenant essentiellement le protocole SSL./Paramètres TLS à utiliser lors d’une connexion SSL/TLS via un SSLSocketFactory
ou un SSLEngine
. Ces propriétés système ne sont que l’origine des valeurs par défaut, qui sont ensuite utilisées par SSLContext.getDefault()
, elle-même utilisée par SSLSocketFactory.getDefault()
par exemple. (Tout cela peut être personnalisé via l'API à plusieurs endroits, si vous ne souhaitez pas utiliser les valeurs par défaut et cet élément spécifique SSLContext
s dans un but donné.)
La différence entre KeyManager
et TrustManager
(et donc entre javax.net.ssl.keyStore
et javax.net.ssl.trustStore
) est la suivante (citée dans le guide de référence de JSSE ):
TrustManager: détermine si les informations d'identification 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 qu'il existe une valeur par défaut pour le magasin de clés de confiance, mais pas pour le magasin de clés.)
Le fichier de clés dans javax.net.ssl.keyStore
est censé contenir vos clés privées et vos certificats, alors que javax.net.ssl.trustStore
contient les certificats d'AC auxquels vous voulez faire confiance lorsqu'une partie distante présente son certificat. Dans certains cas, il peut s'agir d'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).
Pour expliquer de manière usuelle cas/but ou profane:
TrustStore: Comme son nom l'indique, il est normalement utilisé pour stocker les certificats des entités de confiance. Un processus peut conserver un stock de certificats de toutes ses parties de confiance en qui il fait confiance.
keyStore: Utilisé pour stocker les clés du serveur (publiques et privées) avec le certificat signé.
Au cours de la négociation SSL,
Un client tente d'accéder à https: //
Et ainsi, le serveur répond en fournissant un certificat SSL (qui est stocké dans son magasin de clés)
Maintenant, le client reçoit le certificat SSL et le vérifie via trustStore (c'est-à-dire que le trustStore du client dispose déjà d'un ensemble prédéfini de certificats qu'il approuve.). C'est comme: Puis-je faire confiance à ce serveur? Est-ce le même serveur que je suis en train de parler? Aucun homme intermédiaire n'attaque?
Une fois que le client vérifie qu'il communique avec le serveur auquel il fait confiance, la communication SSL peut s'effectuer via une clé secrète partagée.
Remarque: je ne parle pas ici de l’authentification du client côté serveur. Si un serveur souhaite également effectuer une authentification client, il gère également un trustStore pour vérifier le client.
Il n'y a pas de différence entre les fichiers keystore et truststore. Les deux sont des fichiers au format de fichier propriétaire JKS. La distinction est dans l'utilisation: à ma connaissance, Java n'utilisera que le magasin référencé par javax.net.ssl.trustStore
pour rechercher des certificats à approuver lors de la création de connexions SSL. Idem pour les clés et javax.net.ssl.keyStore
. Mais en théorie, il n’est pas difficile d’utiliser un seul et même fichier pour les fichiers de clés de confiance et de confiance.
Le fichier 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. Je l'ai fait dans mon application de production. Voici les étapes à suivre pour générer des certificats Java pour une communication SSL:
keytool -genkey -keystore server.keystore -alias mycert -keyalg RSA -keysize 2048 -validity 3950
keytool -selfcert -alias mycert -keystore server.keystore -validity 3950
keytool -export -alias mycert -keystore server.keystore -rfc -file mycert.cer
keytool -importcert -alias mycert -file mycert.cer -keystore truststore