java.security.cert.CertificateException: les certificats ne sont pas conformes aux contraintes de l'algorithme
J'ai une application de cartographie qui peut ajouter ArcGIS 9.3+ cartes de base à partir d'une URL. Une des URL que je voudrais ajouter provient de l'URL d'un client et est sécurisée. Mon application de cartographie utilisait déjà Java 6 et était capable d'ajouter l'URL sécurisée sans aucun problème. Je suis maintenant passé à Java 7 et je reçois un
"Java.security.cert.CertificateException: Certificates does not conform to algorithm constraints"
exception. Au début, j'estime que c'est le cas, car dans Java 7, l'algorithme MD2 pour la signature de certificats SSL est désactivé par défaut. Vous pouvez le voir dans le fichier Java.security:
"jdk.certpath.disabledAlgorithms=MD2"
Mais lorsque je vérifie le Certification Signature Algorithm de cette URL, il indique SHA-1. Ce qui est encore plus étrange, c’est que si je commente la ligne "jdk.certpath.disabledAlgorithms=MD2" dans le fichier Java.security, l’URL fonctionnera sans problème. Est-ce que MD2 est utilisé ailleurs pendant le processus SSL? Est-ce que j'ai râté quelque chose?
Contexte
Dans la version JDK 6u17, MD2 était largement reconnu comme étant non sécurisé et donc désactivé en Java (voir les notes de version http://www.Oracle.com/technetwork/Java/javase/6u17-141447.html , "Désactiver MD2 dans le certificat chaîne de validation "), ainsi que JDK 7, selon la configuration que vous avez indiquée dans Java.security.
Verisign utilisait un certificat racine de classe 3 avec l'algorithme de signature md2WithRSAEncryption (serial 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf), mais le déconseillait et le remplaçait par un autre certificat portant les mêmes clé et nom, mais signé avec l'algorithme sha1WithRSAEncryption. Cependant, certains serveurs envoient encore l'ancien certificat signé MD2 lors de l'établissement de la liaison SSL (ironiquement, j'ai rencontré ce problème avec un serveur géré par Verisign!).
Vous pouvez vérifier que c'est le cas avec:
openssl s_client -showcerts -connect <server>:<port>
Les versions récentes du JDK (par exemple, 6u21 et toutes les versions publiées de 7) devraient résoudre ce problème en supprimant automatiquement les certificats avec le même émetteur et la même clé publique en tant qu'ancre de confiance (dans cacerts par défaut).
Si vous avez toujours ce problème avec les nouveaux JDK
Vérifiez si vous avez un gestionnaire de confiance personnalisé implémentant l'ancienne interface X509TrustManager. JDK 7+ est censé être compatible avec cette interface. Toutefois, selon mon enquête, lorsque le gestionnaire de confiance implémente X509TrustManager plutôt que le plus récent X509ExtendedTrustManager ( docs ), le JDK utilise son propre wrapper (AbstractTrustManagerWrapper) et contourne en quelque sorte le fichier interne. résoudre ce problème.
La solution consiste à:
utilisez le gestionnaire de confiance par défaut, ou
modifiez votre gestionnaire de confiance personnalisé pour étendre le
X509ExtendedTrustManagerdirectement (simple changement).
Eclipse n'a pas réussi à se connecter aux référentiels SVN https (devrait également s'appliquer à toute application utilisant SSL/TLS).
svn: E175002: La connexion a été fermée: javax.net.ssl.SSLHandshakeException: Java.security.cert.CertificateException: les certificats ne sont pas conformes aux contraintes de l'algorithme.
Le problème était dû à la dernière mise à jour de Java 8 OpenJDK qui désactivait les algorithmes liés à MD5. En guise de solution de contournement jusqu'à l'émission de nouveaux certificats (le cas échéant), modifiez les clés suivantes dans le fichier Java.security.
ATTENTION
N'oubliez pas que cela pourrait avoir des conséquences sur la sécurité, car les algorithmes désactivés sont considérés comme faibles . En guise d'alternative, la solution workaround peut être appliquée sur une machine virtuelle Java via une option de ligne de commande pour utiliser un fichier externe Java.security avec ces modifications, par exemple:Java -Djava.security.properties=/etc/sysconfig/noMD5.Java.security
Pour Eclipse, ajoutez une ligne sur Eclipse.ini sous -vmargs-Djava.security.properties=/etc/sysconfig/noMD5.Java.security
clés d'origine
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
changer à
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768
Le fichier Java.security se trouve dans linux 64 at/usr/lib64/jvm/Java/jre/lib/security/Java.security
Sur Fedora 28, faites attention à la ligne
security.useSystemPropertiesFile = true
de Java.security propriétés.
Fedora 28 a introduit le fichier externe de contrôle disabledAlgorithms à
/etc/crypto-policies/back-ends/Java.config
Vous pouvez modifier ce fichier externe ou l'exclure de Java.security.
Nous avons ce problème avec une base de données que nous ne contrôlons pas et qui nécessitait une autre solution (celles énumérées ici ne fonctionnaient pas). Pour le mien j'avais besoin de:
-Djdk.tls.client.protocols="TLSv1,TLSv1.1"
Je pense que dans mon cas, il s'agissait de forcer un certain ordre.
collègues.
J'ai rencontré ce problème lors du développement de tests d'automatisation pour notre API REST. JDK 7_80 a été installé sur ma machine uniquement. Avant d’installer JDK 8, tout fonctionnait parfaitement et j’avais la possibilité d’obtenir des jetons OAuth 2.0 avec une JMeter. Après avoir installé JDK 8, le cauchemar avec Certificates does not conform to algorithm constraints a commencé.
JMeter et Serenity n’avaient pas la possibilité d’obtenir un jeton. JMeter utilise la bibliothèque JDK pour effectuer la demande. La bibliothèque déclenche simplement une exception lorsque la bibliothèque est appelée à se connecter aux points de terminaison qui l'utilisent, en ignorant la demande.
La prochaine étape consistait à commenter toutes les lignes dédiées à disabledAlgorithms dans TOUS LES FICHIERS Java.security.
C:\Java\jre7\lib\security\Java.security
C:\Java\jre8\lib\security\Java.security
C:\Java\jdk8\jre\lib\security\Java.security
C:\Java\jdk7\jre\lib\security\Java.security
Ensuite, il a finalement commencé à fonctionner. Je sais, c’est une approche brutale, mais c’était le moyen le plus simple de régler le problème.
# jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
# jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
cela se produit probablement car quelque part dans votre chaîne de certificats, vous avez un certificat, plus probablement une ancienne racine, toujours signé avec l'algorithme MD2RSA.
Vous devez le localiser dans votre magasin de certificats et le supprimer.
Retournez ensuite auprès de votre autorité de certification et demandez-leur la nouvelle racine.
Ce sera probablement la même racine avec la même période de validité, mais elle a été recertifiée avec SHA1RSA.
J'espère que cette aide.
J'ai ce problème dans SOAP-UI et aucune solution ci-dessus ne m'a aidé.
La bonne solution pour moi était d'ajouter
-Dsoapui.sslcontext.algorithm = TLSv1
dans le fichier vmoptions (dans mon cas, c'était ...\SoapUI-5.4.0\bin\SoapUI-5.4.0.vmoptions)
Comme ce résultat est le premier résultat renvoyé par Google pour cette erreur, j'ajouterai simplement que si quelqu'un cherche à modifier les paramètres de sécurité Java sans modifier le fichier global Java.security (par exemple, vous devez exécuter des tests), vous pouvez: fournissez simplement un fichier de sécurité prioritaire par le paramètre JVM -Djava.security.properties = votre/fichier/chemin dans lequel vous pouvez activer les algorithmes nécessaires en remplaçant les désactivations.
En utilisant openjdk-7 inside docker, j'ai monté un fichier avec le contenu https://Gist.github.com/dtelaroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security
#Location to mount
/usr/lib/jvm/Java-7-openjdk-AMD64/jre/lib/security/Java.security
Merci @ Luis-Muñoz