Problème
Lorsque JMap/Java essaie d'effectuer une connexion vers un site utilisant HTTPS, un message d'erreur s'affiche indiquant que le certificat SSL n'est pas valide, ex. :
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
Il est possible que le message s'affiche même si le certificat SSL a été installé dans le JVM Keystore.
Ce problème peut être causé par un certificat de type self-signed, invalide, ou un fournisseur de certificat non-reconnu par Java. À la date d'écriture de cet article, seulement 93 fournisseurs de certificats sont reconnus par Java (https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134). Un certificat pourrait donc être bien valide mais non reconnu par JMap/Java.
Solution : Autoriser JMap/Java à utiliser un certificat
Deux solutions sont possibles :
1. Configurer JMap pour qu'il accepte tous les certificats HTTPS même s'il ne peut pas les valider.
Avec cette configuration, JMap acceptera tous les certificats même s'il ne peut pas les valider. Ceci entraine donc un risque de sécurité, si par exemple un site auquel le serveur JMap se connectait était compromis, un tiers parti pourrait possiblement intercepter l'information.
- Ajouter ces deux lignes au fichier bin/startjmapserver.vmoptions :
-Dconnection.ssl.untrusted.allow=true
-Dconnection.ssl.hostname.verify=false - Rédemarrer JMap Server.
2. Ajouter le certificat au 'truststore' de Java du serveur où JMap est installé.
Plusieurs articles décrivent cette procédure (ex. : http://stackoverflow.com/a/9619478). Cette option permet d'ajouter un certificat SSL à la liste des certificats de confiance de Java de sorte à ce que JMap puisse accéder au site comme si Java avait réussi à valider lui-même le certificat. Cette option est donc plus sécuritaire que la première, mais cette configuration est plus complexe et doit être répétée pour chacun des certificats SSL non reconnus ou acceptés par Java.
Si le protocole HTTP est aussi disponible, il pourrait être utilisé mais évidemment ceci serait beaucoup moins sécuritaire que le protocole HTTPS.
English version
Problem
When JMap / Java tries to connect to a site using HTTPS, an error message is displayed stating that the SSL certificate is invalid, ex. :
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
The message may be displayed even though the SSL certificate has been installed in the JVM Keystore.
This problem can be caused by a certificate of self-signed type, invalid, or a certificate provider not recognized by Java. As of the writing date of this article, only 93 certificate providers are recognized by Java (https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134). A certificate could be valid but not recognized by JMap / Java.
Solution:Allow JMap/Java to use a certificate
Two solutions are available:
1. Configure JMap to accept all HTTPS certificates even if it cannot validate them.
With this configuration, JMap will accept all certificates even if it cannot validate them. This poses a security risk, for example if a site to which JMap Server was connected was compromised, a third party could possibly intercept the information.
- Add these lines to the file bin/startjmapserver.vmoptions:
-Dconnection.ssl.untrusted.allow=true
-Dconnection.ssl.hostname.verify=false - Restart JMap Server.
2. Add the certificate to the Java 'truststore' of the server where JMap is installed.
Several articles describe this procedure (ex .: http://stackoverflow.com/a/9619478). This option adds an SSL certificate to the list of trusted Java certificates so that JMap can access the site as if Java had successfully validated the certificate itself. This option is therefore safer than the first, but this configuration is more complex and must be repeated for each of the SSL certificates not recognized or accepted by Java.
If the HTTP protocol is also available, it could be used but obviously this would be much less secure than the HTTPS protocol.