N'avez-vous pas besoin d'un mot de passe pour accéder à un fichier de clés certifiées (créé avec l'outil keytool java)?

Question

Je viens de créer un truststore avec l'outil keytool java (pour l'authentification du serveur d'un serveur qui n'a pas de certificat CA). Cependant, j'ai juste remarqué quelque chose d'étrange. Je commence mon client comme ceci:

java -Djavax.net.ssl.trustStore=<PATHSTUFF>/client.keystore -classpath <STUFF> Client 

(Note: il n'y a pas un mot de passe spécifié)

Les travaux d'appel ci-dessus.

---

Cependant quand j'essayez ceci:

java -classpath <STUFF> Client 

Il ne fonctionne pas. (Évidemment, cela ne fonctionne pas, il faut le truststore).

---

Je comptais besoin de passer dans cette option (mais je ne l'ai pas):

-Djavax.net.ssl.trustStorePassword=mypass 

---

Question: Avez-vous pas besoin d'un mot de passe pour accéder à un truststore? Le mot de passe est-il juste pour la modification? Qu'en est-il d'un fichier de clés?

Answer 1

Le mot de passe est utilisé pour protéger l'intégrité d'un fichier de clés. Si vous ne fournissez aucun mot de passe de magasin, vous pouvez toujours lire le contenu du magasin de clés. La commande keytool -list illustre ce comportement (utilisez-le avec un mot de passe vide).

Answer 2

Si vous ne spécifiez pas de fichier de clés certifiées, celui par défaut est utilisé à la place. Je suppose, vous obtenez une erreur, que vous aurez besoin de spécifier un truststore afin de faire confiance à l'hôte que vous demandez? Le fichier de clés certifiées par défaut réside dans $ JAVA_HOME/lib/security/jssecacerts.

Answer 3

Par défaut, le mot de passe du magasin de confiance JRE est "changeit". Si vous souhaitez modifier par défaut le mot de passe par défaut du magasin de confiance (cacerts) à l'aide de Java, passez par this link.

Answer 4

En plus de @ pascals-Thivent excellente de réponse:

Le mot de passe keystore a deux objectifs - si non fourni, keytool refuse de vous laisser remplacer le contenu du magasin avec un nouveau contenu par exemple en supprimant des entrées de certificat existantes ou en ajoutant de nouvelles.

Bien sûr, si vous avez un accès en écriture pour mettre à jour le fichier keystore en utilisant keytool (ce n'est pas setuid), vous pouvez remplacer le contenu en utilisant un autre outil qui n'a pas vérifié le mot de passe. Et nous savons que le magasin et son format est lisible sans mot de passe, donc nous pouvons probablement écrire ce que nous voulons là-bas.

C'est là qu'intervient le mot de passe de vérification. Lorsque les entrées de magasin sont écrites, le mot de passe de magasin fourni est utilisé pour calculer un condensé du contenu du magasin, tel que salé par le mot de passe. Il s'agit d'un hachage/condensé unidirectionnel, donc sans le mot de passe, vous ne pouvez pas vérifier si le contenu du magasin a été altéré ou non. De même, une personne malveillante qui ne connaît pas le mot de passe ne peut pas non plus modifier le contenu du magasin et produire le digest-hash qui serait produit par ce mot de passe.C'est pourquoi lorsque vous indiquez no-password, keytool vous avertit qu'il ne peut pas vérifier que le magasin n'a pas été falsifié. Si vous fournissez un invalide mot de passe ou le magasin a été falsifié, vous obtiendrez un message différent:

Enter keystore password: keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

keytool n'a pas pu recréer le hachage existant digest à partir du courant stocker le contenu et le mot de passe que vous avez fourni, de sorte que le mot de passe est incorrect, ou le fichier de clés est compromis - keytool ne peut pas dire, mais il suppose que vous ou le logiciel de lecture du magasin sait.

Notez que si le terme keystore est généralement utilisé, il se réfère également à keystores et clés certifiées. Moins généralement, un keystore est le plus souvent un magasin d'identité et contient des identités et leurs clés privées secrètes, telles qu'utilisées par exemple. par un serveur exécutant HTTPS. Un truststore contient plus souvent uniquement des clés publiques et pas de clés privées, donc pas de secrets, mais il est important de déterminer quelles identités un client fait confiance.