Requête sur la jvm truststore et jssecacerts fichier?
j'ai deux https applications web app1 et app2 installé sur deux matous t1 et t2(t1 et t2 sont sur des machines différentes). lorsque dans app1
je fais une url de connexion à app2-je obtenir le handshake SSL erreur. La raison est que je suis en utilisant le certificat auto-signé dans app2 qui n'est pas présent
dans app1 jvm truststore. Donc bonne approche pour le fixer installer le certificat auto-signé en JAVA-HOME/jre/lib/security . Pour faire le
de même , j'ai suivi les étapes indiquées à http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/.
Mêmes mesures sont proposées dans les différents forums. Mais encore obtenir le même SSL handshake erreur qui est
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.
provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
Mais il je me suis débarrassé de cette SSLHandshakeException par les mentionner ci-dessous les paramètres de la JVM fichier de clés certifiées.
-Djavax.net.le protocole ssl.trustStore=C:.fichier de clés
-Djavax.net.le protocole ssl.trustStorePassword=changeit
Ma question ici, c'est pourquoi la première approche(qui est le propre de l'approche) je.e mettre le jssecacerts fichier dans /lib/security n'est pas de travail?
Un autre point est-ce qui est différent entre la première et la deuxième approche ?
OriginalL'auteur M Sach | 2012-03-24
Vous devez vous connecter pour publier un commentaire.
Il n'est pas clair ce que vous essayiez de faire avec ces options. Soit vous utilisez la valeur par défaut truststore (normalement
jssecacerts
, si elle existe; sinon,cacerts
) ou vous pouvez spécifier votre propre..keystore
tend à être utilisé comme un fichier de clés, pas truststore (bien qu'il n'existe pas de valeur par défaut JSSE valeur). (Je voudrais également spécifier le chemin d'accès complet au lieu deC:.keystore
, par la manière.)Il est probablement préférable de faire une copie de l'original de votre
cacerts
(oujssecacerts
) fichier (supprimer les un que vous avez mis, si vous avez changé quelque chose) et ajouter votre certificat distant (c'est à dire app2 cert dans app1 copie et app1 cert dans app2 de la copie, si nécessaire).Vous pouvez afficher la liste des certificats à l'aide de
keytool -list -keystore keystore.jks
(voir l'aide pour plus d'options si besoin).Vous pouvez exporter un certificat à l'aide de
keytool -export -keystore server1-keystore.jks -alias server_alias -file server1.crt
.Puis de l'importer dans l'autre truststore:
keytool -import -keystore client2-truststore.jks -file server1.crt
. (Ici,client2-truststore.jks
sera une copie decacerts
.)Ensuite, configurez votre JVM de Apache Tomcat (pas nécessairement le connecteur Tomcat) pour l'utiliser. Vous devriez être en mesure de définir les paramètres de la JVM dans
catalina.sh
(JAVA_OPTS=-D...
).EDIT:
Pour répondre à votre question plus directement, je viens de vérifié sur une surface propre, Oracle JRE 6 installation (1.6.0_31), et
jssecacerts
l'emporte surcacerts
lorsqu'il est présent (comme indiqué dans le JSSE Réf Guide, donc il ne semble pas être un bug). Je ne suis pas sûr de l'endroit où Oracle ont déménagé Andreas Sterbenz Soleil du blog, donc je ne suis pas sûr de la copie deInstallCert
que vous avez utilisés. Je suppose que quelque chose a mal tourné.Autant que je suis au courant,
InstallCert
se connecte au serveur pour obtenir son certificat (en remplacement de l'étape d'exportation ci-dessus): vous supposez que le certificat que vous obtenez sur votre première connexion est celui de droite (et on peut faire confiance). Vous pouvez également obtenir ce certificat à l'aide d'OpenSSL. Cependant, dans votre cas, vous semblez avoir le contrôle sur les deux serveurs et leurs fichiers de clés, de sorte que vous pourriez aussi bien utiliserkeytool -export
pour être sûr.La première approche (changement de
jssecacerts
) définit la configuration pour toutes les applications qui vont utiliser cette installation de JRE, tandis que le second permettra d'appliquer ces paramètres à la JVM, une fois de Apache Tomcat.Noter, que si vous ne disposez pas d'un
jssecacerts
mais seulement uncacerts
fichier, si vous ne vous importer votre certificat dansjssecacerts
,cacerts
sera ignorée, donc vous ne serez pas en mesure de se connecter aux serveurs qui ont un certificat émis par une autorité de certification qui devrait normalement être approuvées par défaut. C'est pourquoi, en commençant par une copie du fichier par défaut peut être utile. (En outre, si votre application se connecte à d'autres sites qui seraient normalement être approuvées par défaut, ce qui peut aussi expliquer pourquoi vous obtenez ce message d'erreur, à un endroit différent cette fois.)En fin de compte, il est de votre responsabilité de vérifier ce qui est dans
jssecacerts
oucacerts
:Pour votre information: j'ai un fichier cacerts par défaut à l'intérieur de jre\lib\security répertoire non jssecacerts fichier
En regardant les
InstallCert
code, il va générer unjssecacerts
fichier, mais la charge dejssecacerts
oucacerts
, il fait une copie de toute façon. Je ne sais pas pourquoi vous avez eu à redémarrer votre box. Aviez-vous pas de redémarrage de Tomcat après avoir fait ces changements?Comme vous l'avez dit en Regardant la InstallCert code, il va générer un jssecacerts fichier, mais la charge de jssecacerts ou le fichier cacerts, il fait une copie de toute façon. Je pense que ce que vous essayez de dire, c'est, InstallCert code est de faire une copie de tous les certificats présents dans le fichier cacerts à nouveau jssecacets fichier. Donc certificats antérieurs, présents dans le fichier cacerts ne seront pas ignorés. Droit?
En effet, ils doivent être copiés.
OriginalL'auteur Bruno
La différence, c'est que vous avez ajouté le certificat du mauvais fichier truststore :). JRE le système de fichier truststore n'est pas jssecacerts mais simplement le fichier cacerts en vertu de ${JRE_HOME}/lib/security/. Vous avez été la création d'un nouveau fichier de clés certifiées qui le JRE n'est pas conscient. Ajouter le certificat dans le magasin adéquat permettra de résoudre votre problème. Toutefois, permettez-moi de vous avertir que ce n'est pas une bonne idée d'ajouter votre personnalisé certificats d'autorité de certification pour le système de truststore. Les ajouter à l'utilisateur truststore et de l'utiliser de la manière que vous utilisez dans la deuxième option.
Je ne suis pas au courant des chemins de recherche de JRE va jusqu'à trouver dans les magasins. Nic a peut-être raison, mais puisque vous avez déjà essayé de le faire et ça n'a pas fonctionné, je serais forcé de croire qu'il ne fonctionne pas de cette façon. Le Truststore est tout simplement une collection de confiance des certificats des autorités dans un ordre spécifique. L'ajout d'un nouveau certificat auto-signé à la collecte ne fera pas de mal. C'est juste une simple addition.
Mais encore une fois ne pas ajouter vos certificats pour le système truststore parce qu'il aurait une incidence sur tous les JVM instances à l'aide que le JRE. À l'aide de votre propre magasin est une bonne idée.
quand vous dites d'ajouter à l'utilisateur truststore vous dire l'ajout de ces paramètres je.e -Djavax.net.le protocole ssl.trustStore=C:.keystore -Djavax.net.le protocole ssl.trustStorePassword=changeit dans les options jvm de tomcat. Droit?
Cette réponse est tout à fait incorrect. Voir la JSSE Guide de Référence. Java va utiliser jssecacerts si trouvé, sinon le fichier cacerts. Si vous ne connaissez pas ces détails vous ne devriez pas poster à ce sujet.
OriginalL'auteur Drona