wake-up-neo.net

GoDaddy SSL Cert funktioniert nicht mit Java

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.

UPDATE 29.11.2014 - Dies ist immer noch ein Problem, und Godaddy scheint es egal zu sein und wird auch nichts dagegen unternehmen. Es gibt einen Blogeintrag hier von Godaddy VP für Sicherheitsprodukte vor einigen Monaten, der besagt, dass ein Fix auf dem Weg ist und eine vorübergehende Problemumgehung bietet, aber bis heute hat sich nichts geändert. Es ist wichtig zu beachten, dass der G2 CA-Server von Godaddy seit mindestens 5 Jahren in Betrieb ist und Godaddy in dieser Zeit nicht die richtigen Schritte zur Behebung dieses bekannten Problems unternommen hat. Die bereitgestellte Problemumgehung ist genau das, eine Problemumgehung, keine Lösung. Benutzer von Drittanbieter-Diensten haben keine Kontrolle darüber, wie das Zertifikat auf dem Server installiert wird.

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

Hier sind die Kontaktinformationen des SSL-Teams, wenn Sie anrufen möchten:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

UPDATE 17.09.2014 - Dies ist immer noch ein Problem und Godaddy scheint es egal zu sein und wird auch nichts dagegen unternehmen. Ab November, wenn Google alle SHA-1-Zertifikate ablehnt, wird dies ein großes Problem sein. Ich kann jedem nur empfehlen, der sich mit Godaddy in Verbindung setzt und sie hierhin weist.

~

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)

Ich habe einen Mailserver, über den ich versuche, E-Mails von meiner Java-App aus zu senden. Ich kann erfolgreich auf Port 25 senden, damit ich weiß, dass Code funktioniert und alles, aber 25 ist keine verschlüsselte Sitzung. Ich muss TLS auf Port 587 verwenden, für den ein SSL-Zertifikat erforderlich ist. Ich habe ein gültiges SSL-Zertifikat auf dem Server, das von GoDaddy G2 CA signiert ist und seit einiger Zeit installiert ist (keine Probleme).

Mein Problem ist, dass ich die berühmte Fehlermeldung PKIX path building failed: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target erhalte, wenn ich versuche, eine Verbindung herzustellen und eine E-Mail an 587 zu senden.

Nach meinem Verständnis vieler SO Links sowie normaler Google-Fu-Links wird dies normalerweise verursacht, wenn Java dem Zertifikat oder der Zertifizierungsstelle nicht vertraut - wie es bei selbstsignierten Zertifikaten üblich ist. Ich habe mehrere der Online-SSL-Zertifizierungsprüfprogramme verwendet, um sicherzustellen, dass die Kette gültig ist usw. Alles scheint normal zu sein, aber Java verwendet das Zertifikat nicht automatisch.

Mir ist bekannt, dass irgendwo von Sun eine Klassendatei zum Herunterladen und Einrichten des Zertifikats im lokalen Keystore vorhanden ist, damit Java dem Zertifikat vertraut. Dies ist jedoch nicht nur unpraktisch für eine App, die auf mehreren Systemen bereitgestellt wird, sondern auch nur albern für einen Godaddy signiert cert.

Was ist los? Wie kann ich Java veranlassen, das gültige Zertifikat auf dem Server zu verwenden ohne dass Java alle Zertifikate akzeptieren muss?

BEARBEITEN: Ich habe gerade in der Java-Systemsteuerung von Windows (Standardinstallation von JDK 7) nachgesehen und bin sicher, dass unter "Signer CA" der "Issued By: The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority" aufgeführt ist. Also, was gibt es? Mein Zertifikat ist ein Godaddy-Zertifikat ...

UPDATE --

Hier ist die von openssl aus gesehene Zertifikatskette, die in den Kommentaren empfohlen wird:

~]# 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
---

Sieht für mich ok aus, denke ich ...

UPDATE 2 --

Ok, dank @Bruno konnte ich feststellen, dass meine Kette durcheinander geraten ist - ich habe den Server erneut verschlüsselt und nun erscheint meine Kette als solche:

 ~]# 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
---

Welches sieht besser aus als zuvor. - Java gibt weiterhin die gleiche Ausnahme in Bezug auf den Zertifizierungspfad usw. aus. Es scheint also, dass die G2-Zertifizierungskette im Standardschlüsselspeicher von Java 7 noch nicht standardmäßig als vertrauenswürdig eingestuft ist.

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

Nur als Update - Dies ist in der Tat ein GoDaddy-Problem (ich hatte lange Support-E-Mails mit ihnen). Sie haben 2 CA-Server, einer mit dem Namen Class 2 CA und der andere mit dem Namen G2 CA. Ihr Class 2 CA signiert alle SHA-1 Zertifikate, während der G2 CA alle ihre SHA-2 Zertifikate signiert. Hier liegt das Problem: GoDaddy hat den neueren G2 CA-Server nicht zum Java-Standard-Truststore hinzugefügt. Dies führt dazu, dass die Java-Standardinstallationen ihrer Autorität nicht vertrauen und daher Ihrem verketteten Zertifikat nicht vertrauen. Die Umgehung, bis GoDaddy den G2 CA-Server zum Standard-Truststore hinzufügt, besteht darin, Ihr Zertifikat einfach mit SHA-1 neu zu verschlüsseln, um ein vom Class 2 CA-Server signiertes Zertifikat zu erhalten. Für GoDaddy-Kunden ist die erneute Nutzung kostenlos, bis Ihr Zertifikat (offensichtlich) abläuft.

56
SnakeDoc

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.

UPDATE 29.11.2014 - Dies ist immer noch ein Problem, und Godaddy scheint es egal zu sein und wird auch nichts dagegen unternehmen. Es gibt einen Blog-Post[here][1]von Godaddy VP of Security Products von vor einigen Monaten, der behauptet, ein Fix sei auf dem Weg und habe vorübergehend Abhilfe geschaffen, aber bis heute hat sich nichts geändert. Es ist wichtig zu beachten, dass der G2 CA-Server von Godaddy seit mindestens 5 Jahren in Betrieb ist und Godaddy in dieser Zeit nicht die richtigen Schritte zur Behebung dieses bekannten Problems unternommen hat. Die bereitgestellte Problemumgehung ist genau das, eine Problemumgehung, keine Lösung. Benutzer von Drittanbieter-Diensten haben keine Kontrolle darüber, wie das Zertifikat auf dem Server installiert wird.

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

Hier sind die Kontaktinformationen des SSL-Teams, wenn Sie anrufen möchten:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

UPDATE 17.09.2014 - Dies ist immer noch ein Problem und Godaddy scheint es egal zu sein und wird auch nichts dagegen unternehmen. Ab November, wenn Google alle SHA-1-Zertifikate ablehnt, wird dies ein großes Problem sein. Ich kann jedem nur empfehlen, der sich mit Godaddy in Verbindung setzt und sie hierhin weist.

~~~~

Mein erster Beitrag/meine Frage betraf, warum meine Kette nicht funktionierte. Es stellte sich heraus, dass ich ein schlechtes Setup hatte (was schnell mit einigen Ratschlägen von @Bruno und anderen behoben wurde - danke). Als meine korrigierte Kette jedoch immer noch nicht mit Java funktionierte, stellte sich heraus, dass ein viel größeres Problem lauerte. Es hat eine Weile gedauert, aber das Problem liegt tatsächlich bei GoDaddy.

Dies ist in der Tat ein GoDaddy-Problem (ich hatte lange Support-E-Mails mit ihnen).

Sie haben 2 CA-Server, einer mit dem Namen Class 2 CA und der andere mit dem Namen G2 CA. Ihr Class 2 CA signiert alle SHA-1 Zertifikate, während das G2 CA alle ihre SHA-2 Zertifikate signiert.

Hier liegt das Problem - GoDaddy hat den neueren G2 CA Server nicht zum Standard-Java truststore/keystore hinzugefügt - was dazu führt, dass die Standard-Java -Installationen ihrer Autorität nicht vertrauen und daher nicht vertrauen Ihr verkettetes Zertifikat.

Die Umgehung, bis GoDaddy den Server G2 CA zum Standard-Truststore/Keystore hinzufügt, besteht darin, Ihr Zertifikat einfach mit SHA-1 neu zu verschlüsseln, um ein vom Server Class 2 CA signiertes Zertifikat zu erhalten. Für GoDaddy-Kunden ist die erneute Nutzung kostenlos, bis Ihr Zertifikat (offensichtlich) abläuft.

Sobald Sie ein SHA-1 -Zertifikat haben, das vom Class 2 CA -Server signiert wurde, sollte Ihre Vertrauenskette wie erwartet funktionieren und es sind keine benutzerdefinierten Truststore-/Keystore-Importe und/oder Setups erforderlich.

Es freut mich nicht, dass ich ein "schwächeres" Zertifikat verwenden muss, damit es richtig funktioniert, und Diskussionen mit GoDaddy über den E-Mail-Support haben bisher gezeigt, dass sie nicht vorhaben, den G2 CA -Server hinzuzufügen der Standard-Truststore/Keystore. Ich denke, bis sie es hinzufügen, stellen Sie sicher, dass Sie ein SHA-1Class 2 CA signiertes Zertifikat erhalten, wenn Sie vorhaben, mit Java zu arbeiten.

44
SnakeDoc

Die Antworten von Herrn Fixer und Wayne Thayer wurden heruntergestuft, aber sie befürworten tatsächlich die richtigen Umgehungsmöglichkeiten. In der Tat leitet Wayne Thayer GoDaddys SSL-Geschäft, daher weiß er es wahrscheinlich. Sie sollten das Zertifikat "GoDaddy G1 bis G2 Cross" zusammen mit dem Zwischenzertifikat in Ihrer Zertifikatkette installieren.

Ein Downgrade auf SHA1 ist keine ideale Option, da es veraltet ist und Sie in Zukunft mehr Arbeit benötigen werden. Zum Glück hat GoDaddy ein Crossover-Zertifikat zur Verfügung gestellt, das dieses Problem löst. Sie haben Anweisungen veröffentlicht, die Wayne dupliziert hat, und sie sind begraben in den Kommentaren hier .

Ich habe diese Lösung persönlich mit einem SHA2-Zertifikat getestet, und es funktioniert gut. Es ist eine weit überlegene Lösung gegenüber erneutem Tastendruck und Herabstufung auf SHA1. Wenn SHA2 erforderlich ist, ist diese Option ohnehin nicht verfügbar. Möglicherweise gibt es noch Java-Toolchains ohne das neue Zertifikat.

Laut GoDaddy-Support war im Juli 2014 das korrekte Stammzertifikat in den letzten Versionen von Java 8 enthalten, und im September 2014 soll Wayne Thayer von GoDaddy sagte auch , dass das Zertifikat hinzugefügt werden soll Java in den nächsten Monaten ". Ich habe die cacerts-Datei in Java 8 für Mac OS von hier heruntergeladen geprüft und enthält tatsächlich das SHA2-Stammzertifikat.

Also anstatt dass deine Kette so aussieht:

  • Go Daddy Root-Zertifizierungsstelle - G2: (SHA-2) - Hash 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B. Dies ist das Stammzertifikat, das in einigen Systemen (z. B. Chrome) integriert ist. SnakeDoc behauptet, dass "es nicht in Java, Windows CE, Microsoft Exchange und anderen Plattformen integriert ist".
  • 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
  • Ihr SHA2-Zertifikat

Es sollte so aussehen:

  • Go Daddy Klasse 2 Zertifizierungsstelle: (SHA-1) - Hash 27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4. Dies ist das alte Stammzertifikat, das in den meisten Systemen einschließlich Java integriert ist.
  • Go Daddy Root-Zertifizierungsstelle - G2: (SHA-2) - Hash 34 0B 28 80 F4 46 FC C0 4E 59 ED 33 F5 2B 3D 08 D6 24 29 64. Dies ist das sogenannte "GoDaddy G1 to G2 Cross-Zertifikat". .
  • 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
  • Ihr SHA-2-Zertifikat

Siehe auch - Mein Blogbeitrag, der dieses Problem mit Umgehungsmöglichkeiten zusammenfasst.

19

Damit Godaddy-Zertifikate in Java mit SHA2 arbeiten können, müssen Sie ihr Kreuzzertifikat in Ihrer Kette verwenden, um das G2-Stammverzeichnis (SHA2) an das G1-Stammprogramm (SHA1) zu ketten, bis Java beschließt, das Repository zu aktualisieren. Das Cross Certificate Bundle kann hier heruntergeladen werden:

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

GoDaddy-Zertifikatspakete - G2 Mit Kreuz zu G1, einschließlich Root

[Gd_bundle-g2-g1.crt][1] 
13
Mr. Fixer

Mr. Fixer hat recht. Installieren Sie das Zertifikat "GoDaddy G1 nach G2 Cross" zusammen mit dem Zwischenzertifikat in Ihrer Zertifikat-Bundle-Datei. Auf diese Weise können GoDaddy SHA-2-Zertifikate von jedem Client als vertrauenswürdig eingestuft werden, der die SHA-1-Roots einschließlich Java erkennt. Sie erhalten diese Datei von https://certs.godaddy.com/repository Nach der Installation erstellt Java eine Zertifikatskette aus Ihrem Zertifikat, das "GoDaddy Secure Server-Zertifikat (Zwischenzertifikat)" und die " GoDaddy G1 bis G2 Cross-Zertifikat "an die GoDaddy SHA-1-Wurzel. In unserem Repository finden Sie auch eine Bundle-Datei mit dem Cross-Zertifikat. Noch ein letzter Hinweis zu dieser Option: Die Signaturen auf Stammzertifikaten werden nicht geprüft. Wenn Sie also auf einen SHA-1-Stamm angewiesen sind, ist dies genauso sicher wie eine vollständige SHA-2-Zertifikatskette.

11
Wayne Thayer

Folgende Kommentare und die Ausgabe von openssl s_client -connect the.server.name:587 -starttls smtp.

In einer Zertifikatskette sollte cert n von cert n + 1 in der Liste ausgestellt werden: Der Aussteller (i) von cert n sollte der/die Betreff (e) von cert n + 1 sein.

 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

Hier wird cert 0 von cert 1 (Geldstrafe), cert 1 von cert 2 (Geldstrafe) ausgestellt, cert 2 ist selbstsigniert (ebenfalls in Ordnung, dies ist die Stamm-CA).

Zertifikat 2 wird jedoch nicht von Zertifikat 3 ausgestellt. Zertifikat 3 ist falsch platziert (und entspricht wahrscheinlich dem Zertifikat 1). Dies führt wahrscheinlich zu Problemen, da die Kette dadurch ungültig wird.

Sie sollten mindestens cert 3 aus Ihrer Konfiguration entfernen. Darüber hinaus können Sie auch Zert 2 entfernen, da Root-CAs nicht erforderlich sind (der Client muss es trotzdem wissen).

4
Bruno

In der "Java Control Panel" habe ich gerade das Gd Root-Zertifikat zur "Secure Site CA" hinzugefügt und ich habe nicht mehr den cert-Fehler, wenn ich Java verwende. Das von mir hinzugefügte Zertifikat war: Go Daddy Klasse 2-Zertifizierungsstellen-Stammzertifikat - G2

1
lanbrown

wenn Sie das GoDady G2-Bundle in den Java-Schlüsselspeicher importieren, wird das Problem gelöst:

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
1
jpereira

Es klingt, als wäre Ihr Mailserver nicht von Go Daddy Class 2 Certification Authority signiert, sondern tatsächlich von einer seiner Zwischenzertifizierungsstellen. Sie müssen dies für sich selbst überprüfen. Angenommen, das ist der Fall ...

Theoretisch sollte Ihre Software funktionieren - da das Zwischenzertifikat von der Klasse 2-Behörde signiert ist und Sie über die Klasse 2-Autorität im standardmäßigen JDK-Zertifikatspeicher verfügen. Ich habe jedoch festgestellt, dass es nur funktioniert, wenn Sie das Zwischenzertifikat auch Ihrem Zertifikatsspeicher hinzufügen. Hier ist ein Link zu einem Blogbeitrag, der eine ähnliche Erfahrung beschreibt:

http://drcs.ca/blog/adding-godaddy-intermediate-zertifikate-nach-Java-jdk/

Hier ist ein direkter Link zu weiteren GoDaddy-Zwischenzertifikaten: https://certs.godaddy.com/anonymous/repository.pki

Ich kann nicht genau sagen, welches Zertifikat Sie hinzufügen müssen - es hängt davon ab, welche Zertifizierungsstelle in Ihrem Mail-Server verwendet wird.

[aktualisieren]

is there a way to do this programmically?

Könnte sein. Kommt drauf an was du tun möchtest. Ich habe die Klasse Java.security.KeyStore verwendet, um einen privaten Schlüsselspeicher direkt aus Java-Code zu aktualisieren, ohne keytool zu verwenden. Es ist konzeptionell einfach: Laden Sie den Schlüsselspeicher aus einer Datei, lesen Sie das neue Zertifikat, fügen Sie es dem Schlüsselspeicher hinzu und schreiben Sie den Schlüsselspeicher in eine neue Datei. Es dauert jedoch eine Weile, bis die Details richtig sind, und es lohnt sich möglicherweise nicht, nur ein einzelnes Zertifikat zu importieren.

Trotzdem ist es interessant zu versuchen. Checkout KeyStore JavaDoc und lesen Sie die Methoden load, store und setCertificateEntry nach.

1
Guido Simone

Hier können Sie es ausprobieren. Fügen Sie zur Laufzeit den GoDaddy-Stamm und die Zwischenzertifikate zu Trust Manager hinzu. Starten Sie also die Anwendung. 

statischer abschließender String Gd_CERT1 = // "----- BEGIN CERTIFICATE -----" "MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx" + "EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT" + "EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp" + "ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3" + "MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH" + "EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE" + "CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD" + "EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi" + "MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD" + "BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv" + "K/6AYZ15V8TPLvQ/MDxdR/yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am + GZHY23e" + "cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR/Gd71vCxJ1gO7GyQ5HY" + "pDNO6rPWJ0 + tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n" + "eTOvDCAHf + jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB" + "AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV" + "HQ4EFgQUQMK9J47MNIMwojPX + 2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv" + "9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v" + "b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n" + "b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ/MD0wOwYEVR0gADAzMDEG" + "CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv" + "MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv/oV9PBO9sPpyIBslQj6Zz" + 91cxG7685C/b + LrTW + C05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2 " + "RJ17LJ3lXubvDGGqv + QqG + 6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi" + "DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11" + "GIo/ikGQI31bS/6kA1ibRrLDYGCD + H1QQc7CoZDDu + 8CL9IVVO5EFdkKrqeKM + 2x" + "LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB"; // + "----- ENDE CERTIFICATE -----";

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öst die Ausnahme .__ aus. {

    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());
}

Ich habe das codierte von meiner Arbeitsversion kopiert. Es kann also ein Komplikationsfehler auftreten. Sie müssen nur durcharbeiten.

0
junaid

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, ich habe vielleicht eine Lösung für meinen Fall gefunden.

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

Ich habe dies zu meiner Session-Konstruktion hinzugefügt, und jetzt funktioniert es. Dies ist ein Workaround, kein Fix imho, da ich immer noch nicht weiß, warum mein Godaddy SSL-Zertifikat nicht standardmäßig als vertrauenswürdig eingestuft wird. Es ist kein selbstsigniertes Zertifikat.

Jeder kann gerne mitmachen, da ich dieses Problem wirklich verstehen möchte.

0
SnakeDoc