GoDaddy SSL Cert Ne Fonctionne Pas Avec Java

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

Le déclassement en SHA1 n'est pas une option idéale car il est obsolète et vous entraînera plus de travail à l'avenir. Heureusement, GoDaddy a fourni un crossover certificat 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 certificat SHA2, et cela fonctionne bien. C'est une solution bien supérieure par rapport à la nouvelle saisie et au déclassement en SHA1. Lorsque SHA2 devient requis, cette option ne sera pas disponible de toute façon, et il peut toujours y avoir des chaînes d'outils Java sans le nouveau certificat.

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

Donc au lieu de votre chaîne ressemblant à ceci:

• Go Daddy Certificat Racine de l'Autorité – 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 que"ce n'est pas intégré dans Java, Windows CE, Microsoft Exchange et d'autres plates-formes".
• Go Daddy Certificat Sécurisé de l'Autorité – G2: (SHA-2) – Hash 27 AC 93 69 FA F2 52 07 BB 26 27 EC FA CC ÊTRE 4E F9 C3 19 B8
• Votre certificat SHA2

, Il devrait ressembler à ceci:

• Go Daddy Classe 2 Certification Autorité: (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.
• Go Daddy Certificat Racine de l'Autorité – 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 soi-disant "Certificat croisé GoDaddy G1 à G2".
• Go Daddy Secure Certificate Authority – 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 blog résumant ce problème avec des solutions de rechange.

Pour que les certificats Godaddy fonctionnent en Java avec SHA2, vous devrez 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. L'ensemble de certificats croisés peut être téléchargé ici:

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

Bundles de certificats GoDaddy - G2 Avec Croix à G1, inclut la racine

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

M. Fixer a raison. Installez le certificat" GoDaddy G1 to G2 Cross " dans votre fichier bundle 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 cela installé, Java construira une chaîne de certificats de votre certificat vers le "Certificat de serveur sécurisé GoDaddy (Certificat intermédiaire)" vers le "Certificat croisé GoDaddy G1 à G2" à la racine GoDaddy SHA-1. Vous pouvez également trouver un fichier bundle contenant le certificat croisé dans notre référentiel. Une dernière note sur cette option: Les signatures sur les certificats racine ne sont pas vérifiées, donc même si vous comptez sur une racine SHA-1, c'est aussi sécurisé qu'une chaîne de certificats SHA-2 complète.

Après les commentaires et la sortie de openssl s_client -connect the.server.name:587 -starttls smtp.

Dans une chaîne de certificats, le certificat n devrait être émis par le certificat n+1 dans la liste: l'émetteur (i) du certificat n devrait ê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, cert 0 est délivré par le cert 1 (très bien), cert 1 est délivré par le cert 2 (fin), cert 2 est auto-signé (aussi très bien, c'est l'autorité de certification racine).

Cependant, cert 2 n'est pas émis par cert 3. Cert 3 est mal placé (et probablement le même que cert 1). Cela est susceptible de causer des problèmes, car cela rend la chaîne invalide.

Vous devez au moins supprimer cert 3 de votre configuration. De plus, vous pouvez également supprimer cert 2, car avoir un CAS racine n'est pas nécessaire (c'est au client de le savoir de toute façon).

Il semble que votre serveur de messagerie ne soit pas signé par Go Daddy Class 2 Certification Authority, mais est en fait signé par l'une de leurs autorités de certification intermédiaires. Vous aurez besoin de vérifier cela par vous-même. En supposant que cela 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 trouvé que cela ne fonctionne tout simplement pas à moins que vous n'ajoutiez également l'intermédiaire certificat à 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 plus de certificats intermédiaires GoDaddy: https://certs.godaddy.com/anonymous/repository.pki

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

[mise à jour]

is there a way to do this programmically?

Peut-être. Dépend de ce que vous voulez faire. J'ai utilisé la classe java.security.KeyStore pour mettre à jour automatiquement un magasin de clés privé directement à partir du code Java sans utiliser keytool. C'est conceptuellement simple - chargez le magasin de clés à partir d'un fichier, lisez le nouveau certificat, ajoutez-le au magasin de clés, puis écrivez le magasin de clés dans un nouveau fichier. Cependant il faut un certain temps pour obtenir les bons détails et cela ne vaut peut être pas la peine d'en importer un seul certificat.

Pourtant, il est intéressant d'essayer. La caisse KeyStore JavaDoc et de lire sur les load, store et setCertificateEntry méthodes.

Dans le "Panneau de configuration Java", je viens d'ajouter le certificat racine GD à la "Secure Site CA" et je n'ai plus l'erreur de certificat lors de l'utilisation de Java. Le certificat que j'ai ajouté était: Go Daddy Classe 2 Certificat racine de l'Autorité de certification-G2

Si vous importez de GoDady G2 bundle dans le magasin de clés java résout le problème:

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

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 un contournement, pas un correctif à mon humble avis car je ne sais toujours pas pourquoi mon certificat SSL Godaddy n'est pas approuvé par défaut... ce n'est pas une auto-signé cert.

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

Si vous utilisez les propriétés ci-dessous lors de l'envoi d'un courrier, commentez-le. Cela fonctionne pour moi. Mais cela pourrait causer un problème de sécurité.

props.put("mail.smtp.starttls.enable","true");