J'ai une classe qui va télécharger un fichier depuis un https server. Quand je le lance, il renvoie beaucoup d'erreurs. Il semble que j'ai un problème avec mon certificat. Est-il possible d'ignorer l'authentification client-serveur? Si c'est le cas, comment?
package com.da;
import Java.io.FileOutputStream;
import Java.io.IOException;
import Java.nio.CharBuffer;
import Java.util.concurrent.Future;
import org.Apache.http.HttpResponse;
import org.Apache.http.client.utils.URIUtils;
import org.Apache.http.impl.nio.client.DefaultHttpAsyncClient;
import org.Apache.http.nio.IOControl;
import org.Apache.http.nio.client.HttpAsyncClient;
import org.Apache.http.nio.client.methods.AsyncCharConsumer;
import org.Apache.http.nio.client.methods.HttpAsyncGet;
import org.Apache.http.nio.client.methods.HttpAsyncPost;
public class RSDDownloadFile {
static FileOutputStream fos;
public void DownloadFile(String URI, String Request) throws Exception
{
Java.net.URI uri = URIUtils.createURI("https", "176.66.3.69:6443", -1, "download.aspx",
"Lang=EN&AuthToken=package", null);
System.out.println("URI Query: " + uri.toString());
HttpAsyncClient httpclient = new DefaultHttpAsyncClient();
httpclient.start();
try {
Future<Boolean> future = httpclient.execute(
new HttpAsyncGet(uri),
new ResponseCallback(), null);
Boolean result = future.get();
if (result != null && result.booleanValue()) {
System.out.println("\nRequest successfully executed");
} else {
System.out.println("Request failed");
}
}
catch(Exception e){
System.out.println("[DownloadFile] Exception: " + e.getMessage());
}
finally {
System.out.println("Shutting down");
httpclient.shutdown();
}
System.out.println("Done");
}
static class ResponseCallback extends AsyncCharConsumer<Boolean> {
@Override
protected void onResponseReceived(final HttpResponse response) {
System.out.println("Response: " + response.getStatusLine());
System.out.println("Header: " + response.toString());
try {
//if(response.getStatusLine().getStatusCode()==200)
fos = new FileOutputStream( "Response.html" );
}catch(Exception e){
System.out.println("[onResponseReceived] Exception: " + e.getMessage());
}
}
@Override
protected void onCharReceived(final CharBuffer buf, final IOControl ioctrl) throws IOException {
try
{
while (buf.hasRemaining())
{
//System.out.print(buf.get());
fos.write(buf.get());
}
}catch(Exception e)
{
System.out.println("[onCharReceived] Exception: " + e.getMessage());
}
}
@Override
protected void onCleanup() {
try
{
if(fos!=null)
fos.close();
}catch(Exception e){
System.out.println("[onCleanup] Exception: " + e.getMessage());
}
System.out.println("onCleanup()");
}
@Override
protected Boolean buildResult() {
return Boolean.TRUE;
}
}
}
Les erreurs:
URI Query: https://176.66.3.69:6443/download.aspx?Lang=EN&AuthToken=package
Aug 2, 2011 3:47:57 PM org.Apache.http.impl.nio.client.NHttpClientProtocolHandler exception
SEVERE: I/O error: General SSLEngine problem
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at com.Sun.net.ssl.internal.ssl.Handshaker.checkThrown(Unknown Source)
at com.Sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(Unknown Source)
at com.Sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(Unknown Source)
at com.Sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(Unknown Source)
at javax.net.ssl.SSLEngine.wrap(Unknown Source)
at org.Apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.Java:154)
at org.Apache.http.impl.nio.reactor.SSLIOSession.isAppInputReady(SSLIOSession.Java:276)
at org.Apache.http.impl.nio.client.InternalClientEventDispatch.inputReady(InternalClientEventDispatch.Java:79)
at org.Apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.Java:161)
at org.Apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.Java:335)
at org.Apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.Java:315)
at org.Apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.Java:275)
at org.Apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.Java:104)
at org.Apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.Java:542)
at Java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at com.Sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.Sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
at com.Sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
at com.Sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
at com.Sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at com.Sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
at com.Sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.Sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
at Java.security.AccessController.doPrivileged(Native Method)
at com.Sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.Apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.Java:180)
... 9 more
Caused by: Sun.security.validator.ValidatorException: PKIX path building failed: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at Sun.security.validator.PKIXValidator.doBuild(Unknown Source)
at Sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
at Sun.security.validator.Validator.validate(Unknown Source)
at com.Sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
at com.Sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(Unknown Source)
... 16 more
Caused by: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at Sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
at Java.security.cert.CertPathBuilder.build(Unknown Source)
... 21 more
onCleanup()
[DownloadFile] Exception: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
Shutting down
Done
Le problème apparaît lorsque votre serveur a un certificat auto-signé. Pour contourner ce problème, vous pouvez ajouter ce certificat à la liste des certificats de confiance de votre machine virtuelle Java.
Dans cet article author explique comment extraire le certificat de votre navigateur et l'ajouter au fichier cacerts de votre machine virtuelle Java. Vous pouvez soit éditer le fichier Java_HOME/jre/lib/security/cacerts
, soit exécuter votre application avec le paramètre -Djavax.net.ssl.trustStore
. Vérifiez également le JDK/JRE que vous utilisez car cela est souvent source de confusion.
Voir aussi: Comment les noms de serveur de certificat SSL sont-ils résolus/Puis-je ajouter d'autres noms à l'aide de keytool? Si vous rencontrez une exception Java.security.cert.CertificateException: No name matching localhost found
.
Voici ce qui fonctionne de manière fiable pour moi sur macOS. Assurez-vous de remplacer example.com et 443 par le nom d'hôte et le port auxquels vous essayez de vous connecter, puis attribuez un alias personnalisé. La première commande télécharge le certificat fourni à partir du serveur distant et l'enregistre localement au format x509. La deuxième commande charge le certificat enregistré dans le magasin de données de sécurité SSL de Java.
openssl x509 -in <(openssl s_client -connect example.com:443 -prexit 2>/dev/null) -out ~/example.crt
Sudo keytool -importcert -file ~/example.crt -alias example -keystore $(/usr/libexec/Java_home)/jre/lib/security/cacerts -storepass changeit
J'ai eu le même problème avec un certificat générique valide signé de Symantec.
Commencez par exécuter votre application Java avec -Djavax.net.debug = SSL pour voir ce qui se passe réellement.
J'ai fini par importer le certificat intermédiaire}, ce qui causait la rupture de la chaîne de certificats.
J'ai téléchargé le certificat intermédiaire manquant auprès de symantec (vous pouvez voir le lien de téléchargement du certificat manquant dans le journal de négociation SSL: http://svrintl-g3-aia.verisign.com/SVRIntlG3.cer dans mon cas) .
Et j'ai importé le CERT dans le magasin de clés Java. Après avoir importé le certificat intermédiaire, mon certificat SSL générique a finalement commencé à fonctionner:
keytool -import -keystore ../jre/lib/security/cacerts -trustcacerts -alias "VeriSign Class 3 International Server CA - G3" -file /pathto/SVRIntlG3.cer
JRE_HOME/bin
ou JDK/JRE/bin
keytool -keystore ..\lib\security\cacerts -import -alias your.ssl.server.name -file .\relative-path-to-cert-file\your.ssl.server.name.crt
Citer de Plus besoin de "impossible de trouver le chemin de certification valide pour la cible demandée"
lors de la tentative d'ouverture d'une connexion SSL à un hôte utilisant JSSE. Cela signifie généralement que le serveur utilise un certificat de test (éventuellement généré à l'aide de keytool) plutôt qu'un certificat émanant d'une autorité de certification commerciale connue, telle que Verisign ou GoDaddy. Dans ce cas, les navigateurs Web affichent des boîtes de dialogue d’avertissement. Toutefois, JSSE ne pouvant supposer qu’un utilisateur interactif est présent, une exception est simplement émise par défaut.
La validation de certificat est un élément très important de la sécurité SSL, mais je n’écris pas cette entrée pour expliquer les détails. Si cela vous intéresse, vous pouvez commencer par lire le texte de présentation de Wikipedia. J'écris cette entrée pour montrer un moyen simple de parler à cet hôte avec le certificat de test, si vous le souhaitez vraiment.
En gros, vous voulez ajouter le certificat du serveur au magasin de clés avec vos certificats de confiance.
Essayez le code fourni ici. Cela pourrait aider.
La réponse de @Gabe Martin-Dempesy m'a été aidée. Et j'ai écrit un petit script qui s'y rapporte. L'utilisation est très simple.
Installez un certificat de l'hôte:
> Sudo ./Java-cert-importer.sh example.com
Supprimez le certificat déjà installé.
> Sudo ./Java-cert-importer.sh example.com --delete
Java-cert-importer.sh
#!/usr/bin/env bash
# Exit on error
set -e
# Ensure script is running as root
if [ "$EUID" -ne 0 ]
then echo "WARN: Please run as root (Sudo)"
exit 1
fi
# Check required commands
command -v openssl >/dev/null 2>&1 || { echo "Required command 'openssl' not installed. Aborting." >&2; exit 1; }
command -v keytool >/dev/null 2>&1 || { echo "Required command 'keytool' not installed. Aborting." >&2; exit 1; }
# Get command line args
Host=$1; port=${2:-443}; deleteCmd=${3:-${2}}
# Check Host argument
if [ ! ${Host} ]; then
cat << EOF
Please enter required parameter(s)
usage: ./Java-cert-importer.sh <Host> [ <port> | default=443 ] [ -d | --delete ]
EOF
exit 1
fi;
if [ "$Java_HOME" ]; then
javahome=${Java_HOME}
Elif [[ "$OSTYPE" == "linux-gnu" ]]; then # Linux
javahome=$(readlink -f $(which Java) | sed "s:bin/Java::")
Elif [[ "$OSTYPE" == "darwin"* ]]; then # Mac OS X
javahome="$(/usr/libexec/Java_home)/jre"
fi
if [ ! "$javahome" ]; then
echo "WARN: Java home cannot be found."
exit 1
Elif [ ! -d "$javahome" ]; then
echo "WARN: Detected Java home does not exists: $javahome"
exit 1
fi
echo "Detected Java Home: $javahome"
# Set cacerts file path
cacertspath=${javahome}/lib/security/cacerts
cacertsbackup="${cacertspath}.$$.backup"
if ( [ "$deleteCmd" == "-d" ] || [ "$deleteCmd" == "--delete" ] ); then
Sudo keytool -delete -alias ${Host} -keystore ${cacertspath} -storepass changeit
echo "Certificate is deleted for ${Host}"
exit 0
fi
# Get Host info from user
#read -p "Enter server Host (E.g. example.com) : " Host
#read -p "Enter server port (Default 443) : " port
# create temp file
tmpfile="/tmp/${Host}.$$.crt"
# Create Java cacerts backup file
cp ${cacertspath} ${cacertsbackup}
echo "Java CaCerts Backup: ${cacertsbackup}"
# Get certificate from speficied Host
openssl x509 -in <(openssl s_client -connect ${Host}:${port} -prexit 2>/dev/null) -out ${tmpfile}
# Import certificate into Java cacerts file
Sudo keytool -importcert -file ${tmpfile} -alias ${Host} -keystore ${cacertspath} -storepass changeit
# Remove temp certificate file
rm ${tmpfile}
# Check certificate alias name (same with Host) that imported successfully
result=$(keytool -list -v -keystore ${cacertspath} -storepass changeit | grep "Alias name: ${Host}")
# Show results to user
if [ "$result" ]; then
echo "Success: Certificate is imported to Java cacerts for ${Host}";
else
echo "Error: Something went wrong";
fi;
Je pouvais le faire fonctionner avec du code uniquement, c’est-à-dire qu’il n’était pas nécessaire d’utiliser keytool
import com.netflix.config.DynamicBooleanProperty;
import com.netflix.config.DynamicIntProperty;
import com.netflix.config.DynamicPropertyFactory;
import org.Apache.http.client.config.RequestConfig;
import org.Apache.http.config.Registry;
import org.Apache.http.config.RegistryBuilder;
import org.Apache.http.conn.ssl.SSLContexts;
import org.Apache.http.conn.ssl.TrustStrategy;
import org.Apache.http.conn.ssl.X509HostnameVerifier;
import org.Apache.http.impl.nio.client.CloseableHttpAsyncClient;
import org.Apache.http.impl.nio.client.HttpAsyncClients;
import org.Apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager;
import org.Apache.http.impl.nio.reactor.DefaultConnectingIOReactor;
import org.Apache.http.impl.nio.reactor.IOReactorConfig;
import org.Apache.http.nio.conn.NoopIOSessionStrategy;
import org.Apache.http.nio.conn.SchemeIOSessionStrategy;
import org.Apache.http.nio.conn.ssl.SSLIOSessionStrategy;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLSession;
import javax.net.ssl.SSLSocket;
import Java.io.IOException;
import Java.security.cert.CertificateException;
import Java.security.cert.X509Certificate;
public class Test
{
private static final DynamicIntProperty MAX_TOTAL_CONNECTIONS = DynamicPropertyFactory.getInstance().getIntProperty("X.total.connections", 40);
private static final DynamicIntProperty ROUTE_CONNECTIONS = DynamicPropertyFactory.getInstance().getIntProperty("X.total.connections", 40);
private static final DynamicIntProperty CONNECT_TIMEOUT = DynamicPropertyFactory.getInstance().getIntProperty("X.connect.timeout", 60000);
private static final DynamicIntProperty SOCKET_TIMEOUT = DynamicPropertyFactory.getInstance().getIntProperty("X.socket.timeout", -1);
private static final DynamicIntProperty CONNECTION_REQUEST_TIMEOUT = DynamicPropertyFactory.getInstance().getIntProperty("X.connectionrequest.timeout", 60000);
private static final DynamicBooleanProperty STALE_CONNECTION_CHECK = DynamicPropertyFactory.getInstance().getBooleanProperty("X.checkconnection", true);
public static void main(String[] args) throws Exception
{
SSLContext sslcontext = SSLContexts.custom()
.useTLS()
.loadTrustMaterial(null, new TrustStrategy()
{
@Override
public boolean isTrusted(X509Certificate[] chain, String authType) throws CertificateException
{
return true;
}
})
.build();
SSLIOSessionStrategy sslSessionStrategy = new SSLIOSessionStrategy(sslcontext, new AllowAll());
Registry<SchemeIOSessionStrategy> sessionStrategyRegistry = RegistryBuilder.<SchemeIOSessionStrategy>create()
.register("http", NoopIOSessionStrategy.INSTANCE)
.register("https", sslSessionStrategy)
.build();
DefaultConnectingIOReactor ioReactor = new DefaultConnectingIOReactor(IOReactorConfig.DEFAULT);
PoolingNHttpClientConnectionManager connectionManager = new PoolingNHttpClientConnectionManager(ioReactor, sessionStrategyRegistry);
connectionManager.setMaxTotal(MAX_TOTAL_CONNECTIONS.get());
connectionManager.setDefaultMaxPerRoute(ROUTE_CONNECTIONS.get());
RequestConfig requestConfig = RequestConfig.custom()
.setSocketTimeout(SOCKET_TIMEOUT.get())
.setConnectTimeout(CONNECT_TIMEOUT.get())
.setConnectionRequestTimeout(CONNECTION_REQUEST_TIMEOUT.get())
.setStaleConnectionCheckEnabled(STALE_CONNECTION_CHECK.get())
.build();
CloseableHttpAsyncClient httpClient = HttpAsyncClients.custom()
.setSSLStrategy(sslSessionStrategy)
.setConnectionManager(connectionManager)
.setDefaultRequestConfig(requestConfig)
.build();
httpClient.start();
// use httpClient...
}
private static class AllowAll implements X509HostnameVerifier
{
@Override
public void verify(String s, SSLSocket sslSocket) throws IOException
{}
@Override
public void verify(String s, X509Certificate x509Certificate) throws SSLException {}
@Override
public void verify(String s, String[] strings, String[] strings2) throws SSLException
{}
@Override
public boolean verify(String s, SSLSession sslSession)
{
return true;
}
}
}
Pour ceux qui aiment Debian et Java préemballé:
Sudo mkdir /usr/share/ca-certificates/test/ # don't mess with other certs
Sudo cp ~/tmp/test.loc.crt /usr/share/ca-certificates/test/
Sudo dpkg-reconfigure --force ca-certificates # check your cert in curses GUI!
Sudo update-ca-certificates --fresh --verbose
N'oubliez pas de vérifier /etc/default/cacerts
pour:
# enable/disable updates of the keystore /etc/ssl/certs/Java/cacerts
cacerts_updates=yes
Pour supprimer le certificat:
Sudo rm /usr/share/ca-certificates/test/test.loc.crt
Sudo rm /etc/ssl/certs/Java/cacerts
Sudo update-ca-certificates --fresh --verbose
Pour Windows uniquement, procédez comme suit:
La source de cette erreur sur mon instance Apache 2.4 (à l'aide d'un certificat générique Comodo) était un chemin incomplet du certificat racine signé SHA-1. Le certificat émis comportait plusieurs chaînes et la chaîne menant au certificat racine SHA-1 manquait d'un certificat intermédiaire . Les navigateurs modernes savent comment gérer cela, mais Java 7 ne le gère pas par défaut (bien qu'il existe certaines manières compliquées de le faire dans le code). Il en résulte des messages d'erreur qui semblent identiques au cas des certificats auto-signés:
Caused by: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at Sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.Java:196)
at Java.security.cert.CertPathBuilder.build(CertPathBuilder.Java:268)
at Sun.security.validator.PKIXValidator.doBuild(PKIXValidator.Java:380)
... 22 more
Dans ce cas, le message "Impossible de trouver un chemin de certification valide pour la cible demandée" est généré en raison du certificat intermédiaire manquant. Vous pouvez vérifier quel certificat est manquant en utilisant SSL Labs test sur le serveur. Une fois que vous avez trouvé le certificat approprié, téléchargez-le et (si le serveur est sous votre contrôle), ajoutez-le à l'ensemble de certificats. Vous pouvez également importer le certificat manquant localement. Résoudre ce problème sur le serveur est une solution plus générale au problème.
Cela peut également être dû à l'utilisation de certificats GoDaddy avec Java 7 signés à l'aide de SHA2.
Chrome et tous les autres navigateurs commencent à déprécier les certificats SSL signés à l'aide de SHA1, car ils ne sont pas aussi sécurisés.
Plus d'informations sur le problème peuvent être trouvés ici , ainsi que sur la façon de le résoudre sur votre serveur si vous en avez besoin maintenant.
AVG version 18.1.3044 (avec Windows 10) interfère avec mon application Spring locale.
Solution: entrez dans la section AVG intitulée "Web et messagerie" et désactivez la "protection de la messagerie" . AVG bloque le certificat si le site n'est pas sécurisé.
MISE À JOUR: Qu'un redémarrage aidé était une coïncidence (je l'espérais, hourra!). La cause réelle du problème était la suivante: lorsque Gradle doit utiliser un magasin de clés spécifique, ce dernier doit également contenir tous les certificats racine officiels. Sinon, il ne peut pas accéder aux bibliothèques des référentiels classiques. Ce que je devais faire était ceci:
Importez le certificat auto-signé:
keytool -import -trustcacerts -alias myselfsignedcert -file /Users/me/Desktop/selfsignedcert.crt -keystore ./privateKeystore.jks
Ajoutez les certificats racine officiels:
keytool -importkeystore -srckeystore <Java-home>/lib/security/cacerts -destkeystore ./privateKeystore.jks
Peut-être que le démon Gradle s'est aussi mis en travers. Cela pourrait valoir la peine de tuer tous les démons en cours d'exécution trouvés avec ./gradlew --status
si les choses commencent à s’aggraver.
AFFICHAGE ORIGINAL:
Personne ne le croira, je sais. Cependant, si tout échoue, essayez: Après un redémarrage de mon Mac, le problème avait disparu. Grrr.
Contexte: ./gradlew jar m'a gardé "incapable de trouver le chemin de certification valide pour la cible demandée"
Je suis coincé avec un certificat auto-signé, enregistré à partir du navigateur, importé dans privateKeystore.jks. Puis il a demandé à Gradle de travailler avec privateKeystore.jks:
org.gradle.jvmargs=-Djavax.net.debug=SSL -Djavax.net.ssl.trustStore="/Users/me/IntelliJ/myproject/privateKeystore.jks" -Djavax.net.ssl.trustStorePassword=changeit
Comme mentionné, cela n'a fonctionné qu'après un redémarrage.
J'ai eu le même problème avec l'erreur de certificats et c'était à cause de SNI, et le client http que j'ai utilisé ne faisait pas implémenter SNI. Donc, une mise à jour a fait le travail
<dependency>
<groupId>org.Apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.6</version>
</dependency>
Vous avez deux options: importer le certificat auto-signé dans le magasin de clés Java pour chaque fichier jvm sur lequel le logiciel s'exécutera ou essayer la fabrique SSL non validante:
jdbc:postgresql://myserver.com:5432/mydatabasename?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
Dans mon cas, le fichier de clés et le fichier de clés certifiées étaient dotés du même certificat. Parfois, la chaîne de certificats peut poser problème si vous avez plusieurs copies de certificats.
Assurez-vous que les https://176.66.3.69:6443/ ont un certificat valide .. vous pouvez le vérifier d'abord via le navigateur si cela fonctionne dans le navigateur, il fonctionnera en Java.
ça marche pour moi
Cela a résolu mon problème,
Nous devons importer le certificat sur le Java local. Sinon, nous pourrions obtenir l'exception ci-dessous.
javax.net.ssl.SSLHandshakeException: Sun.security.validator.ValidatorException: la construction du chemin PKIX a échoué: Sun.security.provider.certpath.SunCertPathBuilderException: impossible de trouver un chemin de certification valide pour la cible demandée à Sun.security.ssl.Alerts.getSSLException (Alerts.Java:192) à Sun.security.ssl.SSLSocketImpl.fatal (SSLSocketImpl.Java:1949) à Sun.security.ssl.Handshaker.fatalSE (Handshaker.Java:302)
SSLPOKE est un outil permettant de tester la connectivité https à partir de votre ordinateur local.
Commande pour tester la connectivité:
"%Java_HOME%/bin/Java" SSLPoke <hostname> 443
Sun.security.validator.ValidatorException: la création du chemin PKIX a échoué: Sun.security.provider.certpath.SunCertPathBuilderException: impossible de trouver le chemin de certification valide de la cible demandée sur Sun.security.validator.PKIXValidator.doBuild (PKIXValidator.Java:387) à Sun.security.validator.PKIXValidator.engineValidate (PKIXValidator.Java:292) sur Sun.security.validator.Validator.validate (Validator.Java:260) à Sun.security.ssl.X509TrustManagerImpl.validate (X509TrustManagerImpl.Java:324) à Sun.security.ssl.X509TrustManagerImpl.checkTrusted (X509TrustManagerImpl.Java:229) sur Sun.security.ssl.X509TrustManagerImpl.checkServerTrusted (X509TrustManagerImpl.Java:124) sur Sun.security.ssl.ClientHandshaker.serverCertificate (ClientHandshaker.Java:1496) à Sun.security.ssl.ClientHandshaker.processMessage (ClientHandshaker.Java:216) à Sun.security.ssl.Handshaker.processLoop (Handshaker.Java:1026) à Sun.security.ssl.Handshaker.process_record (Handshaker.Java:961) à Sun.security.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.Java:1062) à Sun.security.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.Java:1375) à Sun.security.ssl.SSLSocketImpl.writeRecord (SSLSocketImpl.Java:747) sur Sun.security.ssl.AppOutputStream.write (AppOutputStream.Java:123) sur Sun.security.ssl.AppOutputStream.write (AppOutputStream.Java:138) à SSLPoke.main (SSLPoke.Java:31) Causé par: Sun.security.provider.certpath.SunCertPathBuilderException: impossible de trouver le chemin de certification valide vers cible demandée à Sun.security.provider.certpath.SunCertPathBuilder.build (SunCertPathBuilder.Java:141) sur Sun.security.provider.certpath.SunCertPathBuilder.engineBuild (SunCertPathBuilder.Java:126) sur Java.security.cert.CertPathBuilder.build (CertPathBuilder.Java:280) sur Sun.security.validator.PKIXValidator.doBuild (PKIXValidator.Java:382) ... 15 autres
keytool -import -alias brinternal -keystore "%Java_HOME%/jre/lib/security/cacerts" -file <cert path>
il serait tout d’abord invité à «Entrer le mot de passe du magasin de clés:» changeit est le mot de passe par défaut. et enfin l'invite "Faites confiance à ce certificat? [non]:", indiquez "oui" pour ajouter le certificat au magasin de clés.
Verfication:
C:\tools>"%Java_HOME%/bin/Java" SSLPoke <hostname> 443
Successfully connected
tout d’abord, téléchargez le certificat SSL, puis vous pouvez accéder à votre chemin bin Java en exécutant la commande ci-dessous dans la console.
C:\Java\JDK1.8.0_66-X64\bin>keytool -printcert -file C:\Users\lova\openapi.cer -keystore openapistore
Voici comment j'ai pu résoudre le problème: http://code.naishe.in/2011/07/looks-like-article-no-more-unable-to.html
Dans mon cas, j'utilise MacOs High Sierra avec Java 1.6. Le fichier cacert se trouve à un emplacement différent de celui mentionné ci-dessus dans la réponse de Gabe Martin-Dempesy. Le fichier cacert était également déjà lié à un autre emplacement (/ Bibliothèque/Internet Plug-Ins/JavaAppletPlugin.plugin/Sommaire/Accueil/lib/security/cacerts).
À l'aide de FireFox, j'ai exporté le certificat du site Web en question dans un fichier local appelé "exportsCertFile.crt". De là, j'ai utilisé keytool pour déplacer le certificat dans le fichier cacert. Cela a résolu le problème.
bash-3.2# cd /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/
bash-3.2# keytool -importcert -file ~/exportedCertFile.crt -alias example -keystore cacerts -storepass changeit