Warum funktioniert der SSL-handshake geben 'Konnte nicht erzeugen DH-Schlüsselpaar' Ausnahme?
Wenn ich eine SSL-Verbindung mit IRC-Server (in anderen aber nicht - vermutlich weil die server das bevorzugte Verschlüsselungsverfahren) bekomme ich die folgende exception:
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
... 3 more
Letzte Ursache:
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
... 10 more
Ein Beispiel von einem server, wird dieses problem veranschaulicht, ist die Blende.esper.net:6697 (dies ist ein IRC-server). Ein Beispiel für einen server, der nicht nachweisen das problem ist kornbluth.freenode.net:6697. [Nicht überraschend, alle Server auf jedem Netzwerk teilen die gleiche entsprechende Verhalten.]
Mein code (die, wie erwähnt funktioniert bei der Verbindung zu einigen SSL-Server):
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, trustAllCerts, new SecureRandom());
s = (SSLSocket)sslContext.getSocketFactory().createSocket();
s.connect(new InetSocketAddress(host, port), timeout);
s.setSoTimeout(0);
((SSLSocket)s).startHandshake();
Ist es, die letzten startHandshake, dass die Ausnahme ausgelöst. Und ja, es gibt einige Magische Los mit den "trustAllCerts'; code Kräfte, die das SSL-system ist nicht überprüfen certs. (Also... nicht ein cert-problem.)
Offensichtlich eine Möglichkeit ist, dass esper-server ist falsch konfiguriert, aber ich suchte und nicht finden irgendwelche anderen Hinweise, um Menschen, die Probleme mit esper SSL-ports, und "openssl" eine Verbindung zu (siehe unten). Also ich wundere mich, wenn dies ist eine Einschränkung von Java-Standard-SSL-Unterstützung oder so etwas. Irgendwelche Vorschläge?
Hier ist, was passiert, wenn ich eine Verbindung zu aperture.esper.net 6697 mit 'openssl' von der Kommandozeile:
~ $ openssl s_client -connect aperture.esper.net:6697
CONNECTED(00000003)
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify return:1
---
Certificate chain
0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
Server certificate
-----BEGIN CERTIFICATE-----
[There was a certificate here, but I deleted it to save space]
-----END CERTIFICATE-----
subject=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
No client certificate CA names sent
---
SSL handshake has read 2178 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 51F1D40A1B044700365D3BD1C61ABC745FB0C347A334E1410946DCB5EFE37AFD
Session-ID-ctx:
Master-Key: DF8194F6A60B073E049C87284856B5561476315145B55E35811028C4D97F77696F676DB019BB6E271E9965F289A99083
Key-Arg : None
Start Time: 1311801833
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
Wie bereits erwähnt, nach allem, was er tut, erfolgreich eine Verbindung herstellen, das ist mehr, als man sagen kann, für meine Java-app.
Sollte es relevant sein, ich bin mit OS X 10.6.8 Java version 1.6.0_26.
Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
. Keine Ahnung, welche Größe gesendet wurde, durch den server hier, und was die Spezifikation sagt über diese.Tatsächlich können Sie sehen, die Größe, die der server verwendet in der
openssl
Ausgang in der Frage: "Cipher is DHE-RSA-AES256-SHA, Server public key is 2048 bit". Und 2048 > 1024 :-).nicht genau.
Server public key (size)
war, und ist, der Schlüssel in der cert. s_client
im Jahr 2011 nicht zeigen, ephemeren Schlüssel, 1.0.2 im Jahr 2015 und bis nicht, wie Server Temp Key
mehrere Zeilen höher. Obwohl ein guter server meistens machen die DHE-Größe wie RSA-auth Größe.
InformationsquelleAutor sam | 2011-07-27
Du musst angemeldet sein, um einen Kommentar abzugeben.
Das problem ist die wichtigste Größe. Die maximale akzeptable Größe, dass Java akzeptiert ist 1024 bit. Dies ist ein bekanntes Problem (siehe JDK-6521495).
Den bug-report, die ich verlinkt erwähnt Abhilfe mit BouncyCastle die JCE-Implementierung. Hoffentlich, das sollte für Sie arbeiten.
UPDATE
Dies berichtet als bug JDK-7044060 und festen vor kurzem.
Beachten Sie jedoch, dass die Grenze wurde angehoben auf 2048-bit. Für die Größen > 2048 bit, es ist JDK-8072452 - Entfernen Sie die maximale prime Größe von DH-Schlüssel; das Update erscheint für den 9.
Danke. Scheint ein ziemlich ernstes problem, angesichts der Existenz von Servern, die verlangen, eine größere Größe! 🙁 Ich habe versucht, BouncyCastle; wenn Sie es als preferred provider stürzt es mit einer anderen Ausnahme (seufz), und ich kann nicht sehen, eine offensichtliche Weise zu verwenden, dass nur für DH. Allerdings fand ich eine alternative Lösung, die werde ich hinzufügen, als eine neue Antwort. (Es ist nicht schön.)
Cool. Dies wurde behoben in neueren Versionen von Java. Aber meine Frage ist über die Verwendung der älteren version.. Wenn ich mit einer älteren version manchmal funktioniert es und manchmal gibt es oben Ausnahme..Warum so willkürlich Verhalten? Wenn Ihr ein bug in java, dann denke ich, es sollte nie zu arbeiten?
Die BouncyCastle - JCE provider-Implementierung arbeitete für mich
Die 2048 Update wurde zurück portiert auf IcedTea 2.5.3 . Neuere Versionen von IcedTea erhöht es auf 4096.
InformationsquelleAutor Vivin Paliath
Die "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" Antwort nicht für mich arbeiten, aber Die BouncyCastle - JCE-Anbieter Vorschlag hat.
Hier sind die Schritte, die ich nahm, die mit Java 1.6.0_65-b14-462 auf Mac OSC 10.7.5
1) Laden Sie diesen Gläsern:
bcprov-jdk15on-154.jar
bcprov-ext-jdk15on-154.jar
2) verschieben Sie diese Gläser $JAVA_HOME/lib/ext
3) Bearbeiten $JAVA_HOME/lib/security/java.Sicherheit wie folgt:
Sicherheit.Anbieter.1=org.bouncycastle.jce.Anbieter.BouncyCastleProvider
neu starten-app mit JRE und probieren Sie es
Sicherheit.Anbieter.2=org.bouncycastle.jce.Anbieter.BouncyCastleProvider haben, besser zu arbeiten, indem es auf 1. führte zu Fehlern in der Standard-software.
Dies funktioniert für mich auch, aber ich habe einen Anbieter Hinzugefügt dynamisch. Reffer meine Antwort für details hier.
Vielen Dank, es funktioniert auf java 1.6
Dank eine Tonne, funktionierte für mich und war erforderlich, um erfolgreich zu bauen, die Tomcat 7.0.78 Quelle.
InformationsquelleAutor mjj1409
Hier ist meine Lösung (java 1.6), wäre auch interessiert, warum ich dies tun musste:
Bemerkte ich aus den javax.Sicherheit.debug=ssl, das manchmal auch die verwendeten cipher-suite ist TLS_DHE_... und irgendwann ist es TLS_ECDHE_.... Die später passieren würde, wenn ich Hinzugefügt BouncyCastle. Wenn TLS_ECDHE_ ausgewählt wurde, die MEISTE Zeit hat es geklappt, aber nicht IMMER, so dass es noch BouncyCastle provider war unzuverlässig, scheiterte mit dem gleichen Fehler, jedes zweite mal oder so). Ich denke, irgendwo in der Sonne SSL-Implementierung, die manchmal wählen DHE, manchmal kann man es sich aussuchen ECDHE.
Also die Lösung hier gepostet stützt sich auf die Beseitigung TLS_DHE_ Chiffren völlig. HINWEIS: BouncyCastle ist NICHT erforderlich für die Lösung.
So legen Sie die server-Zertifikatsdatei von:
Speichern Sie diese als später auf Sie verwiesen wird, als hier, ist die Lösung für ein SSL-http-get ohne die TLS_DHE_ cipher suites.
Endlich hier ist, wie es verwendet wird (certFilePath wenn Sie den Pfad des Zertifikats gespeichert von openssl):
jdk.tls.disabledAlgorithms=DHE, ECDHE
imJDK_HOME/jre/lib/security/java.security
auch funktioniert und vermeiden Sie alle diese Codes.Nur das deaktivieren der DHE bei mir funktioniert:
jdk.tls.disabledAlgorithms=DHE
. Mit 1.7.0_85-b15.Hinzugefügt jdk.tls.disabledAlgorithms=DHE, ECDHE in JDK_HOME/jre/lib/security/java.Sicherheit und fein gearbeitet! Danke!!! Mit 1.7.0_79
Nicht deaktivieren ECDHE. Es ist anders als die DHE und nicht mal Primzahlen.
Kann mir bitte jemand sagen wie ich die 'certFilePath'. Ich Hänge schon länger an diesem für eine Woche. @Zsozso
InformationsquelleAutor Zsozso
Die Antwort oben ist richtig, aber in Bezug auf den workaround hatte ich Probleme mit der BouncyCastle-Implementierung, wenn ich es als preferred provider:
Dies ist auch besprochen in einem thread im forum habe ich gefunden, die erwähnen nicht die Lösung.
http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems
Fand ich eine alternative Lösung, die funktioniert für meinen Fall, ich bin zwar nicht glücklich mit ihm. Die Lösung ist es so eingerichtet, dass ein Algorithmus der Diffie-Hellman-Algorithmus ist gar nicht verfügbar. Dann, angenommen, dass der server unterstützt einen alternativen Algorithmus, es werden die Auswahl während der normalen Verhandlung. Offensichtlich ist der Nachteil dieser Lösung ist, dass, wenn jemand irgendwie schafft, finden Sie einen server, der nur unterstützt Diffie-Hellman 1024 bit oder weniger, dann heißt das eigentlich, es wird nicht funktionieren, wo es verwendet, um Arbeit vor.
Hier ist der code, den die Werke gegeben, ein SSLSocket (bevor Sie es anschließen):
Böse.
Ich bin neu in java Wertpapiere. Bitte um Hilfe, wo soll ich schreiben, dieses Stück code?
Ich habe versucht, jede Lösung in diesem thread und das war die einzige, die arbeitete mit meinem ibm jvm (ibm-java-s390x-60).
Was die variable s in ((SSLSocket)s) ?
InformationsquelleAutor sam
Können Sie deaktivieren Sie die DHE-ganz in deiner jdk, Bearbeiten jre/lib/security/java.Sicherheit und stellen Sie sicher, dass DER deaktiviert ist, zB. wie
jdk.tls.disabledAlgorithms=SSLv3, DHE
.das ist nur im JDK 1.7 und höher. link
Das problem bei mir gelöst JDK 1.8.0_144-b01
InformationsquelleAutor Tor
Können Sie die Installation der provider dynamisch:
1) Laden Sie diesen Gläsern:
bcprov-jdk15on-152.jar
bcprov-ext-jdk15on-152.jar
2) Kopieren Sie die jar-Dateien zum
WEB-INF/lib
(oder der classpath -)3) Add-provider dynamisch:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
...
Security.addProvider(new BouncyCastleProvider());
funktioniert bei mir nicht
Danke! dieser arbeitete für mich. In meinem Fall war es itext importieren bcp 1.4 verursachen E-Mails zu google zu scheitern.
Tnx, es arbeitete für mich auch. 🙂
Ich bin immer javax.net.ssl.SSLHandshakeException: nicht Unterstützte curveId: 29 mit der java-version 1.6.0_27
InformationsquelleAutor angelcorral
Dies ist ein ziemlich Alter post, aber wenn Sie Apache HTTPD, können Sie begrenzen die DH-Größe.
Sehen http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
InformationsquelleAutor Bertl
Wenn Sie mit jdk1.7.0_04, upgrade auf jdk1.7.0_21. Das problem wurde behoben, dass update.
Problem besteht immer noch mit JDK 1.7.0_25
Aktualisierung der jre für mich gearbeitet .hatte 6.22 aktualisiert 7.59 . das problem ist gelöst.
Ich bin mit dem JDK 1.7.0_79. Nicht für mich arbeiten
Upgrade auf JDK 1.8.0_73 für mich gearbeitet.
InformationsquelleAutor Lekkie
Versuchen, den Download der "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" aus dem Java-download-Website und ersetzen Sie die Dateien in Ihrer JRE.
Dieser arbeitete für mich, und ich brauchte nicht einmal zu verwenden BouncyCastle - die standard Sun JCE war in der Lage, eine Verbindung zum server herstellen.
PS. Ich bekam die gleiche Fehlermeldung (ArrayIndexOutOfBoundsException: 64), wenn ich habe versucht, mit BouncyCastle bevor Sie die Richtlinie ändern von Dateien, so scheint es, unsere situation ist sehr ähnlich.
haben Sie getan, anyhting sonst? oder einfach nur kopiert die 2 Dateien in den Ordner?
Es ist schon eine Weile her, aber soweit ich mich erinnere, war, dass alle ich tun musste. Abgesehen von einem Neustart alle Laufenden Java-Prozesse danach aus.
Funktioniert bei mir nicht.
InformationsquelleAutor mjomble
Wenn Sie noch gebissen von diesem Problem UND Apache ' httpd-v> 2.4.7, versuchen Sie dies: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
kopiert aus der url:
Beginnend mit version 2.4.7, mod_ssl verwenden DH-Parameter, die zählen Primzahlen mit einer Länge von mehr als 1024 bit. Java 7 und früher begrenzen Ihre Unterstützung für DH-prime-Größen zu einem maximum von 1024 bit, jedoch.
Wenn Ihr Java-basierten client bricht mit Ausnahmen, wie zum Beispiel java.lang.RuntimeException: could not generate DH-Schlüsselpaar und java.Sicherheit.InvalidAlgorithmParameterException: Prime Größe muss Vielfaches von 64 ist, und kann nur ein Bereich von 512 bis 1024 (inklusive) und httpd-logs tlsv1 alert interner Fehler (SSL alert number 80) (auf LogLevel "info" oder höher), können Sie entweder neu anordnen mod_ssl s cipher Liste mit SSLCipherSuite (möglicherweise in Verbindung mit SSLHonorCipherOrder), oder Sie können benutzerdefinierte DH-Parameter, die mit einem 1024-bit-Primzahl, die immer Vorrang vor allen von den built-in DH-Parameter.
Generieren benutzerdefinierte DH-Parameter, verwenden Sie die
Befehl. Alternativ können Sie verwenden Sie den folgenden standard-1024-bit-DH-Parameter aus RFC 2409, Abschnitt 6.2:
Hinzufügen von benutzerdefinierten Parametern, einschließlich "BEGIN DH PARAMETERS" und "END DH PARAMETERS" - Zeilen am Ende des ersten Zertifikat-Datei, die Sie konfiguriert haben, verwenden Sie die Direktive SSLCertificateFile.
Ich bin mit java 1.6 auf der client-Seite, und es löste mein Problem. Ich habe nicht gesenkt cipher suites oder wie, aber Hinzugefügt eine benutzerdefinierte generierten DH-param zu den cert-Datei..
InformationsquelleAutor pka
Ist es möglich, dass Sie falsche Maven-Abhängigkeiten.
Sie müssen diese Bibliotheken im Maven-dependency-Hierarchie:
Wenn Sie diese Abhängigkeiten, das ist der Fehler, und das sollten Sie tun:
Beurteilung der Abhängigkeit:
Ausschließen, diese Abhängigkeiten aus dem Artefakt, das das falsche Abhängigkeiten, in meinem Fall ist es:
Es ist für mich gearbeitet.
InformationsquelleAutor Jose Antonio Sánchez Pujante
Ich habe das gleiche problem mit Yandex Maps-server, JDK 1.6 und Apache 4.2.1 HttpClient. Der Fehler war
mit aktiviertem Debuggen von
-Djavax.net.debug=all
gab es eine Nachricht in ein log -Habe ich behoben, dieses problem durch hinzufügen BouncyCastle-Bibliothek
bcprov-jdk16-1.46.jar
und registrieren, die ein Anbieter in einem Karten-service-KlasseEinem Anbieter registriert ist, bei der ersten Verwendung von
MapService
.Ich update meine Antwort.
InformationsquelleAutor v.ladynev
Löste das problem durch ein Upgrade auf JDK 8.
InformationsquelleAutor anre
Ich mit coldfusion 8 auf JDK 1.6.45 und hatte Probleme, dass ich nur rote Kreuze statt Bildern, und auch mit cfhttp nicht in der Lage, eine Verbindung zum lokalen webserver mit ssl.
mein test-script zu reproduzieren mit coldfusion 8 wurde
dies gab mir die ziemlich Allgemeine Fehlermeldung " I/O Exception: peer nicht authentifiziert."
Ich habe dann versucht, hinzufügen von Zertifikaten der server mit root-und intermediate-Zertifikate für den java-keystore und auch die coldfusion-keystore, aber nichts half.
dann habe ich ausgetestet, das problem mit
und bekam
und
Hatte ich dann die Idee, dass der webserver (apache in meinem Fall) hatte sehr moderne Chiffren für die ssl-und die ist ziemlich restriktiv (qualys-score a+) und verwendet eine starke diffie hellmann Schlüssel mit mehr als 1024 bit. offensichtlich, coldfusion und java jdk 1.6.45 kann nicht gelingen.
Der nächste Schritt in der odysee war, zu denken, die Installation eines alternativen security-Anbieter für java, und ich entschied mich für die Hüpfburg.
siehe auch http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/
Ich dann heruntergeladen, die
vom http://www.bouncycastle.org/latest_releases.html und installiert es unter
C:\jdk6_45\jre\lib\ext oder wo immer das jdk ist in der ursprünglichen Installation von coldfusion 8 unter C:\JRun4\jre\lib\ext aber ich benutze ein neueres jdk (1.6.45), die sich außerhalb der coldfusion-Verzeichnis. es ist sehr wichtig, um die bcprov-ext-jdk15on-156.jar in der \ext-Verzeichnis (dies kostete mich etwa zwei Stunden und ein paar Haare 😉
dann habe ich die Datei bearbeitet C:\jdk6_45\jre\lib\security\java.security (mit wordpad nicht mit editor.exe!) und setzen Sie in eine Zeile für den neuen Anbieter. danach wird die Liste sah wie
(siehe die neuen in position 1)
dann starten Sie den coldfusion-Dienst vollständig.
Sie können dann
und genießen Sie das Gefühl...
und natürlich
was für eine Nacht und was für ein Tag. Hoffentlich wird dies helfen, die (teilweise oder vollständig), um jemand da draußen. wenn Sie Fragen haben, mailen Sie mir einfach an info ... (domain siehe oben).
InformationsquelleAutor Raffael Meier
Traf ich den SSL-Fehler, die auf einem CentOS-server mit JDK 6.
Mein plan war, zu installieren, ein höheres JDK-version (JDK 7) zu co-existieren mit JDK 6, aber es stellt sich heraus, dass lediglich die Installation der neueren JDK mit
rpm -i
war nicht genug.Den JDK-7-installation nur dann gelingen würde, mit der
rpm -U
upgrade-option, wie unten dargestellt.1. Download JDK 7
2. RPM-installation schlägt fehl,
3. U /MIN-upgrade erfolgreich
4. Bestätigen Sie die neue version
InformationsquelleAutor Saheed
Wenn der server unterstützt eine Chiffre, die nicht-DH, Sie können erzwingen, dass den client zu wählen, die Verschlüsselung und vermeiden Sie die DH-Fehler. Wie:
Beachten Sie, dass die Angabe einer genauen Ziffer-ist anfällig für Bruch im langen Lauf.
InformationsquelleAutor Jason Martin
Wir haben die gleichen genauen Ausnahmefehler zurückgegeben, um es zu beheben war einfach nach Stunden im internet zu surfen.
Wir heruntergeladen die neueste version von jdk, die wir finden konnten, auf oracle.com, installiert es und zeigte Jboss application-server in das Verzeichnis des installierten neuen jdk.
Jboss neu gestartet, um wieder aufbereitete, problemo behoben!!!
InformationsquelleAutor Peter Azuka Molokwu
Ich habe diesen Fehler mit Bamboo 5.7 + Gradle-Projekt + Apache. Gradle versucht, einige Abhängigkeiten von einem unserer Server über SSL.
Lösung:
mit OpenSSL:
Beispiel-Ausgabe:
Append-output zur Zertifikat-Datei (bei Apache -
SSLCertificateFile
param)Apache neu starten
Neu Starten, Bambus
Versuchen, zu bauen-Projekt wieder
InformationsquelleAutor Evgeny Lebedev
Ich verwendet, um einen ähnlichen Fehler beim Zugriff auf svn.apache.org mit java SVN-clients über ein IBM-JDK. Derzeit svn.apache.org die Benutzer der clients cipher-preferences.
Nach zu laufen, nur einmal mit einem packet capture /javax.net.debug=ALL, ich war in der Lage, auf die blacklist setzen, nur einen einzigen cipher DHE und Dinge, die für mich arbeiten (ECDHE wird verhandelt statt).
Eine schöne schnelle Lösung, wenn es nicht leicht ist, den client.
InformationsquelleAutor covener
Seit kurzem habe ich das gleiche Problem und nach dem Upgrade jdk-version von 1.6.0_45 zu jdk1.7.0_191, die das Problem behoben hat.
InformationsquelleAutor Sam
Sich für mich die folgende Befehlszeile das Problem:
java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true
-Djavax.net.debug=ssl:handshake XXXXX.jar
Ich bin mit dem JDK 1.7.0_79
InformationsquelleAutor rico-chango