Le certificat SSL GoDaddy ne fonctionne pas avec Java

Question

UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust store. If possible, it's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

MISE À JOUR 29/11/2014 - C'est toujours un problème et Godaddy ne semble pas s'en soucier ni ne veut rien faire à ce sujet. Il y a un article de blog ici de Godaddy, vice-président des produits de sécurité de plusieurs mois, annonçant qu'un correctif était sur le point de se produire et fournissait une solution temporaire, mais rien n'a changé jusqu'à présent. Il est important de noter que le serveur CA G2 CA de Godaddy existe depuis au moins 5 ans et que, depuis ce temps, Godaddy n'a pas pris les mesures appropriées pour résoudre ce problème connu. La solution proposée n’est que cela, une solution, pas une solution. Les utilisateurs de services tiers n'ont aucun contrôle sur la manière dont le certificat est installé sur le serveur.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

Voici les coordonnées de leur équipe SSL si vous êtes enclin à appeler:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

MISE À JOUR 17/09/2014 - C’est toujours un problème et Godaddy ne semble pas s’en soucier ni ne veut rien faire à ce sujet. En novembre, lorsque Google dépréciera tous les certificats SHA-1, cela deviendra un problème majeur. Je recommande fortement à toute personne qui peut contacter Godaddy et la diriger ici.

~

tl;dr; - final update with current solution/workaround at the bottom of this post (it is a GoDaddy problem and there is a workaround until they fix it)

J'ai un serveur de messagerie auquel j'essaie d'envoyer du courrier depuis mon application Java. Je peux envoyer sur le port 25 avec succès, donc je sais que le code fonctionne et tout, mais que 25 n'est pas une session cryptée. J'ai besoin d'utiliser TLS sur le port 587 qui nécessite un cert SSL. J'ai un certificat SSL valide sur le serveur qui est signé par GoDaddy G2 CA et qui est en place depuis un moment maintenant (aucun problème).

Mon problème est que je reçois le célèbre message d'erreur PKIX path building failed: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target lors d'une tentative de connexion et d'envoi de courrier sur 587.

D'après ma compréhension de nombreux SO ainsi que de google-fu normaux, cela est généralement dû au fait que Java ne fait pas confiance au cert ou à l'autorité de certification - comme il est courant pour un cert auto-signé. J'ai utilisé plusieurs des vérificateurs de certificats SSL en ligne pour m'assurer que la chaîne est valide, etc. Tout semble être normal ... mais Java n'utilisera pas le certificat automatiquement.

Je suis conscient du fait qu’il existe un fichier de classe quelque part dans Sun qui téléchargera et installera le certificat dans le magasin de clés local afin que Java lui fasse confiance ... mais ceci n’est pas seulement peu pratique pour une application qui sera déployée sur plusieurs systèmes, mais simplement. idiot pour un cert signé par Godaddy.

Que se passe-t-il? Comment faire en sorte que Java utilise le certificat valide sur le serveur sans obliger Java à accepter tous les certificats?

EDIT: Je viens de regarder dans mon panneau de configuration Java sous Windows (installation par défaut de jdk 7) et bien sûr, sous Signer CA, le nom Emis par: The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority est répertorié ... alors que donne-t-il? Mon cert est un cert Godaddy ...

UPDATE --

Voici la chaîne de certificats telle que vue depuis la commande openssl recommandée dans les commentaires:

~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 3 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 ---

Ca me va, je pense ...

UPDATE 2 --

Ok, grâce à @Bruno, j'ai pu déterminer que ma chaîne était foirée - j'ai ressaisi la clé du serveur et maintenant ma chaîne apparaît comme telle:

 ~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 ---

Ce qui semble mieux qu'avant. - Java lève toujours la même exception concernant le chemin du certificat, etc. Il apparaît donc que la chaîne de certificats G2 n'est pas, par défaut, encore approuvée dans le magasin de clés par défaut de Java 7.

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

Juste comme une mise à jour - Ceci est en effet un problème de GoDaddy (j'ai eu de longs e-mails d'assistance avec eux). Ils ont 2 serveurs d'autorité de certification, l'un appelé Class 2 CA et l'autre appelé G2 CA. Leur Class 2 CA signe tous les certificats SHA-1, tandis que le G2 CA signe tous leurs certificats SHA-2. C’est là que réside le problème: GoDaddy n’a pas ajouté son serveur G2 CA plus récent au fichier de clés certifiées Java par défaut. Ainsi, les installations Java par défaut ne font pas confiance à son autorité et ne font donc pas confiance à votre certificat chaîné. La solution de rechange jusqu'à ce que GoDaddy ajoute le serveur G2 CA au fichier de clés certifiées par défaut consiste simplement à ressaisir votre certificat à l'aide de SHA-1 as-to pour obtenir un certificat signé par le serveur Class 2 CA. Le rekeying est gratuit pour les clients GoDaddy jusqu'à l'expiration de votre certificat (évidemment).

SnakeDoc · Accepted Answer

UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust store. If possible, it's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

MISE À JOUR 29/11/2014 - C'est toujours un problème et Godaddy ne semble pas s'en soucier ni ne veut rien faire à ce sujet. Il y a un blog post[here][1]de Godaddy, vice-président des produits de sécurité d'il y a plusieurs mois, affirmant qu'un correctif était sur le point d'arriver et qu'il offrait une solution temporaire, mais rien n'a changé à ce jour. Il est important de noter que le serveur CA G2 CA de Godaddy existe depuis au moins 5 ans et que, depuis ce temps, Godaddy n'a pas pris les mesures appropriées pour résoudre ce problème connu. La solution proposée n’est que cela, une solution, pas une solution. Les utilisateurs de services tiers n'ont aucun contrôle sur la manière dont le certificat est installé sur le serveur.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

Voici les coordonnées de leur équipe SSL si vous êtes enclin à appeler:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

MISE À JOUR 17/09/2014 - C’est toujours un problème et Godaddy ne semble pas s’en soucier ni ne veut rien faire à ce sujet. En novembre, lorsque Google dépréciera tous les certificats SHA-1, cela deviendra un problème majeur. Je recommande fortement à toute personne qui peut contacter Godaddy et la diriger ici.

~~~~

Mon post/question initial concernait pourquoi ma chaîne ne fonctionnait pas. Il est devenu évident que j'avais une mauvaise configuration (qui a été rapidement corrigée avec les conseils de @Bruno et d'autres - merci). Cependant, lorsque ma chaîne corrigée ne fonctionnait toujours pas avec Java, il était devenu évident qu'un problème beaucoup plus important se cachait. Cela a pris un certain temps, mais le problème est en fait avec GoDaddy.

C’est en fait un problème de GoDaddy (j’ai eu de longs e-mails d’assistance avec eux).

Ils ont 2 serveurs d'autorité de certification, l'un appelé Class 2 CA et l'autre appelé G2 CA. Leur Class 2 CA signe tous les certificats SHA-1, tandis que le G2 CA signe tous leurs certificats SHA-2.

C’est là que réside le problème - GoDaddy n’a pas ajouté son plus récent serveur G2 CA au système par défaut Java truststore/keystore, ce qui a pour effet que les installations par défaut Java ne font pas confiance à ses droits. votre certificat chaîné.

La solution de rechange jusqu'à ce que GoDaddy ajoute le serveur G2 CA au fichier de clés/magasin de clés par défaut consiste simplement à ressaisir votre certificat à l'aide de SHA-1 pour obtenir un certificat signé par le serveur Class 2 CA. Le rekeying est gratuit pour les clients GoDaddy jusqu'à l'expiration de votre certificat (évidemment).

Une fois que vous avez un certificat SHA-1 signé par le serveur Class 2 CA, votre chaîne de confiance doit fonctionner comme prévu et aucune importation et/ou installation personnalisée de magasin de clés/magasins de clés n'est requise.

Cela ne me rend pas heureux de devoir utiliser un certificat "plus faible" afin de le faire fonctionner correctement, et des discussions avec GoDaddy par le biais du support par courrier électronique ont indiqué à ce jour qu'ils n'avaient aucun plan pour ajouter le serveur G2 CA à le magasin de clés par défaut/keystore. Je suppose que jusqu’à ce qu’ils l’ajoutent, assurez-vous d’obtenir un certificat signé par le serveur SHA-1 Class 2 CA si vous envisagez de travailler avec Java.

Isaac Potoczny-Jones · Answer

Les réponses de M. Fixer et de Wayne Thayer ont été rejetées, mais elles préconisent en réalité les solutions de rechange correctes. En fait, Wayne Thayer dirige le commerce SSL de GoDaddy, alors il le sait probablement. Vous devez installer le certificat "GoDaddy G1 à G2 Cross" dans votre chaîne de certificats avec le certificat intermédiaire.

La mise à niveau vers SHA1 n'est pas une option idéale, car elle est obsolète et vous occasionnera plus de travail. Heureusement, GoDaddy a fourni un certificat croisé qui résout ce problème. Ils ont posté des instructions, que Wayne a dupliquées, et ils sont enterrés dans les commentaires ici .

J'ai personnellement testé cette solution avec un cert SHA2 et cela fonctionne bien. C’est une solution bien supérieure à celle de recomposer et de rétrograder vers SHA1. Lorsque SHA2 devient obligatoire, cette option n'est de toute façon pas disponible et il se peut qu'il existe encore des chaînes d'outils Java sans le nouveau certificat.

Selon l'assistance de GoDaddy, à compter de juillet 2014, le certificat racine correct était inclus dans les versions récentes de Java 8 et, en septembre 2014, Wayne Thayer de GoDaddy a également déclaré que le certificat "devait être ajouté à Java dans les prochains mois ". J'ai vérifié le fichier cacerts dans Java 8 pour Mac OS téléchargé à partir d'ici , et il contient effectivement le certificat racine SHA2.

Donc, au lieu que votre chaîne ressemble à ceci:

Autorité de certification Go Daddy Root - G2: (SHA-2) - Hash 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B. Il s’agit du certificat racine intégré à certains systèmes (par exemple, Chrome). SnakeDoc affirme qu '"il n'est pas intégré à Java, Windows CE, Microsoft Exchange et d'autres plates-formes".
Autorité de certification Go Daddy Secure - G2: (SHA-2) - Hash 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
Votre certificat SHA2

Ça devrait ressembler à ça:

Autorité de certification de la classe 2 de Go Daddy: (SHA-1) - Hash 27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4. Il s’agit de l’ancien certificat racine intégré à la plupart des systèmes, y compris Java.
Autorité de certification Go Daddy Root - G2: (SHA-2) - Hash 34 0B 28 80 F4 46 FC C0 4E 59 ED 33 F5 2B 3D 08 D6 24 29 64. Il s'agit du «certificat croisé GoDaddy G1 à G2». .
Autorité de certification Go Daddy Secure - G2: (SHA-2) - Hash 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
Votre certificat SHA-2

Voir aussi - mon article de blog résumant ce problème avec des solutions de rechange.

Mr. Fixer · Answer

Pour que les certificats Godaddy fonctionnent en Java avec SHA2, vous devez utiliser leur certificat croisé dans votre chaîne pour chaîner la racine G2 (SHA2) à la racine G1 (SHA1) jusqu'à ce que Java décide de mettre à jour leur référentiel. Le kit de certification croisée peut être téléchargé ici:

https://certs.godaddy.com/anonymous/repository.pki

Paquets de certificats GoDaddy - G2 avec croix vers G1, comprend une racine

[Gd_bundle-g2-g1.crt][1]

https://certs.godaddy.com/anonymous/repository.pki

Paquets de certificats GoDaddy - G2 avec croix vers G1, comprend une racine

[Gd_bundle-g2-g1.crt][1]

Wayne Thayer · Answer

M. Fixer a raison. Installez le certificat "GoDaddy G1 à G2 Cross" dans votre fichier de jeu de certificats avec le certificat intermédiaire. Cela permet aux certificats GoDaddy SHA-2 d'être approuvés par tout client qui reconnaît les racines SHA-1, y compris Java. Vous pouvez obtenir ce fichier à partir de https://certs.godaddy.com/repository Une fois installé, Java créera une chaîne de certificats de votre certificat au "Certificat GoDaddy Secure Server (certificat intermédiaire)" au Certificat croisé GoDaddy G1 à G2 "à la racine GoDaddy SHA-1. Vous pouvez également trouver un fichier bundle contenant la certification croisée dans notre référentiel. Une dernière remarque sur cette option: les signatures sur les certificats racine ne sont pas vérifiées. Ainsi, même si vous vous basez sur une racine SHA-1, celle-ci est tout aussi sécurisée qu'une chaîne de certificats SHA-2 complète.

Bruno · Answer

Suite aux commentaires et à la sortie de openssl s_client -connect the.server.name:587 -starttls smtp.

Dans une chaîne de certificats, le certificat n doit être émis par le certificat n + 1 de la liste: l'émetteur (i) du certificat n doit être le (s) sujet (s) du certificat n + 1.

 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 3 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2

Ici, le certificat 0 est émis par le certificat 1 (amende), le certificat 1 est délivré par le certificat 2 (amende), le certificat 2 est auto-signé (également, il s'agit de la racine CA).

Cependant, le cert 2 n'est pas délivré par le cert 3. Le cert 3 est égaré (et probablement le même que le cert 1). Cela est susceptible de poser des problèmes car cela rend la chaîne invalide.

Vous devriez au moins retirer le cert 3 de votre configuration. En outre, vous pouvez également supprimer le certificat 2, car il n'est pas nécessaire d'avoir des autorités de certification racines (le client doit le savoir de toute façon).

lanbrown · Answer

Dans le "Panneau de configuration Java", je viens d'ajouter le certificat racine Gd à "l'autorité de certification de site sécurisé" et je n'ai plus l'erreur de certificat lors de l'utilisation de Java. Le certificat que j’ai ajouté était le suivant: Certificat racine du certificat d’autorité de certification Go Daddy de classe 2 - G2

jpereira · Answer

si vous importez le kit GoDady G2 dans le magasin de clés Java, le problème est résolu:

export Java_HOME=/usr/lib/jvm/Java-8-Oracle/ wget https://certs.godaddy.com/repository/Gd_bundle-g2.crt $Java_HOME/bin/keytool -import -alias root -file ./Gd_bundle-g2.crt -storepass changeit -trustcacerts -keystore $Java_HOME/jre/lib/security/cacerts

Guido Simone · Answer

On dirait que votre serveur de messagerie n’est pas signé par Go Daddy Class 2 Certification Authority, mais qu’il est en fait signé par l’une de leurs autorités de certification intermédiaires. Vous devrez vérifier cela par vous-même. En supposant que ce soit le cas ...

En théorie, votre logiciel devrait fonctionner - puisque le certificat intermédiaire est signé par l'autorité de classe 2 et que vous avez l'autorité de classe 2 dans le magasin de certificats JDK par défaut. Cependant, j’ai constaté que cela ne fonctionnait tout simplement pas, à moins d’ajouter le certificat intermédiaire à votre magasin de certificats. Voici un lien vers un article de blog décrivant une expérience similaire:

http://drcs.ca/blog/adding-godaddy-intermediate-certificates-to-Java-jdk/

Voici un lien direct vers d’autres certificats intermédiaires GoDaddy: https://certs.godaddy.com/anonymous/repository.pki

Je ne peux pas vous dire exactement quel certificat vous devez ajouter - cela dépend de l'autorité de certification utilisée sur votre serveur de messagerie.

[mettre à jour]

is there a way to do this programmically?

Peut être. Cela dépend de ce que vous voulez faire. J'ai utilisé la classe Java.security.KeyStore pour mettre à jour automatiquement un fichier de clés privé directement à partir de code Java sans utiliser keytool. C'est un concept simple: charger le fichier de clés à partir d'un fichier, lire le nouveau certificat, l'ajouter au fichier de clés, puis l'écrire dans un nouveau fichier. Cependant, il faut un certain temps pour obtenir les détails nécessaires et il ne vaut peut-être pas la peine d'importer un seul certificat.

Pourtant, il est intéressant d'essayer. Checkout KeyStore JavaDoc et lisez les méthodes load, store et setCertificateEntry.

junaid · Answer

Voici ce que vous pouvez essayer. Ajoutez la racine GoDaddy et les certificats intermédiaires au gestionnaire de confiance au moment de l'exécution. Je commence si l'application.

static final String Gd_CERT1 = // "----- COMMENCEZ LE CERTIFICAT -----" "MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx" + "EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUXGjAYBgNVBAoT" + "EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp" + "ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3" + "MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH" + "EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE" + "CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD" + "EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi" + "MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD" + "BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv" + "K/6AYZ15V8TPLvQ/MDxdR/yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am + GZHY23e" + "cSZHjzhHU9FGHbTj3ADqRay9vHHqqm8A29vNMDp5T19MR/Gd71vCxJ1gO7GyQ5HY" + "pDNO6rPWJ0 + tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n" + "eTOvDCAHf + jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB" + "AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV" + "HQ4EFgQUQMK9J47MNIMwojPX + 2yz8LQsgM4wHwYDVR0jBBwwoAUOpqFBxBnKLbv" + "9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v" + "b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n" + "b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ/MD0wOwYEVR0gADAzMDEG" + "CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv" + "MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv/oV9PBO9sPpyIBslQj6Z" + "91cxG7685C/b + LrTW + C05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2". + "RJ17LJ3lXubvDGGqv + QqG + 6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi" + "DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11" + "GIo/ikGQI31bS/6kA1ibRrLDYGCD + H1QQc7CoZDDu + 8CL9IVVO5EFdkKrqeKM + 2x" + "LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB"; // + "----- CERTIFICAT DE FIN -----";

static final String Gd_CERT2 = //"-----BEGIN CERTIFICATE-----" "MIIEfTCCA2WgAwIBAgIDG+cVMA0GCSqGSIb3DQEBCwUAMGMxCzAJBgNVBAYTAlVT" +"MSEwHwYDVQQKExhUaGUgR28gRGFkZHkgR3JvdXAsIEluYy4xMTAvBgNVBAsTKEdv" +"IERhZGR5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMTAx" +"MDcwMDAwWhcNMzEwNTMwMDcwMDAwWjCBgzELMAkGA1UEBhMCVVMxEDAOBgNVBAgT" +"B0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoTEUdvRGFkZHku" +"Y29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRpZmljYXRlIEF1" +"dGhvcml0eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv3Fi" +"CPH6WTT3G8kYo/eASVjpIoMTpsUgQwE7hPHmhUmfJ+r2hBtOoLTbcJjHMgGxBT4H" +"Tu70+k8vWTAi56sZVmvigAf88xZ1gDlRe+X5NbZ0TqmNghPktj+pA4P6or6KFWp/" +"3gvDthkUBcrqw6gElDtGfDIN8wBmIsiNaW02jBEYt9OyHGC0OPoCjM7T3UYH3go+" +"6118yHz7sCtTpJJiaVElBWEaRIGMLKlDliPfrDqBmg4pxRyp6V0etp6eMAo5zvGI" +"gPtLXcwy7IViQyU0AlYnAZG0O3AqP26x6JyIAX2f1PnbU21gnb8s51iruF9G/M7E" +"GwM8CetJMVxpRrPgRwIDAQABo4IBFzCCARMwDwYDVR0TAQH/BAUwAwEB/zAOBgNV" +"HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDqahQcQZyi27/a9BUFuIMGU2g/eMB8GA1Ud" +"IwQYMBaAFNLEsNKR1EwRcbNhyz2h/t2oatTjMDQGCCsGAQUFBwEBBCgwJjAkBggr" +"BgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMDIGA1UdHwQrMCkwJ6Al" +"oCOGIWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2Ryb290LmNybDBGBgNVHSAEPzA9" +"MDsGBFUdIAAwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly9jZXJ0cy5nb2RhZGR5LmNv" +"bS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWQtTvZKGEacke+1bMc8d" +"H2xwxbhuvk679r6XUOEwf7ooXGKUwuN+M/f7QnaF25UcjCJYdQkMiGVnOQoWCcWg" +"OJekxSOTP7QYpgEGRJHjp2kntFolfzq3Ms3dhP8qOCkzpN1nsoX+oYggHFCJyNwq" +"9kIDN0zmiN/VryTyscPfzLXs4Jlet0lUIDyUGAzHHFIYSaRt4bNYC8nY7NmuHDKO" +"KHAN4v6mF56ED71XcLNa6R+ghlO773z/aQvgSMO3kwvIClTErF0UZzdsyqUvMQg3" +"qm5vjLyb4lddJIGvl5echK1srDdMZvNhkREg5L4wn3qkKQmw4TRfZHcYQFHfjDCm" +"rw=="; //+"-----END CERTIFICATE-----"; static final String Gd_CERT3 = //"-----BEGIN CERTIFICATE-----" "MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh" +"MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE" +"YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3" +"MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo" +"ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg" +"MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN" +"ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA" +"PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w" +"wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi" +"EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY" +"avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+" +"YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE" +"sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h" +"/t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5" +"IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj" +"YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD" +"ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy" +"OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P" +"TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ" +"HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER" +"dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf" +"ReYNnyicsbkqWletNw+vHX/bvZ8="; //+"-----END CERTIFICATE-----";

public static void main (String [] args) lève Exception {

 TrustManagerFactory dtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); dtmf.init((KeyStore) null); // gets you the default trust manager X509TrustManager defaultTm = null; for (TrustManager tm : dtmf.getTrustManagers()) { if (tm instanceof X509TrustManager) { defaultTm = (X509TrustManager) tm; break; } } CertificateFactory cf = CertificateFactory.getInstance("X.509"); byte [] decoded = Base64.getDecoder().decode(Gd_CERT1); ByteArrayInputStream in = new ByteArrayInputStream(decoded); Certificate ca1 = cf.generateCertificate(in); in.close(); decoded = Base64.getDecoder().decode(Gd_CERT2); in = new ByteArrayInputStream(decoded); Certificate ca2 = cf.generateCertificate(in); in.close(); decoded = Base64.getDecoder().decode(Gd_CERT3); in = new ByteArrayInputStream(decoded); Certificate ca3 = cf.generateCertificate(in); in.close(); String keyStoreType = KeyStore.getDefaultType(); KeyStore ks = KeyStore.getInstance(keyStoreType); ks.load(null, null); ks.setCertificateEntry("cert1", ca1); ks.setCertificateEntry("cert2", ca2); ks.setCertificateEntry("cert3", ca3); TrustManagerFactory gdtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); gdtmf.init(ks); X509TrustManager gdTm = null; for (TrustManager tm : gdtmf.getTrustManagers()) { if (tm instanceof X509TrustManager) { gdTm = (X509TrustManager) tm; break; } } TrustManager tms[] = new TrustManager[2]; tms[0] = gdTm; tms[1] = defaultTm; try { SSLContext sslCtx = SSLContext.getInstance("TLS"); sslCtx.init(null, tms, new SecureRandom()); } catch (Java.security.GeneralSecurityException e) { e.printStackTrace(); throw e; } HttpsURLConnection.setDefaultSSLSocketFactory(sslCtx.getSocketFactory()); }

J'ai copié le code de ma version de travail. donc il pourrait y avoir une erreur de complication. vous avez juste besoin de travailler à travers ceux-ci.

SnakeDoc · Answer

Update - this "solution" is no longer valid (see my above accepted answer) - keeping this answer because it did help alleviate the problem so long as the side-effects are tolerable.

Ok, j'ai peut-être trouvé une solution pour mon cas.

props.put("mail.smtp.ssl.trust", "smtp.somecompany.com");

J'ai ajouté ceci à ma construction de session, et maintenant cela fonctionne. Ceci est une solution de contournement, pas une solution à mon humble avis, car je ne sais toujours pas pourquoi mon certificat SSL Godaddy n’est pas fiable par défaut… ce n’est pas un certificat auto-signé.

N'importe qui, n'hésitez pas à intervenir car j'aimerais vraiment comprendre ce problème.