it-swarm.com.de

Warum gibt SSL-Handshake die Ausnahme "DH-Schlüsselpaar konnte nicht generiert werden" aus?

Wenn ich eine SSL-Verbindung mit einigen IRC) Servern herstelle (aber nicht mit anderen - vermutlich aufgrund der bevorzugten Verschlüsselungsmethode des Servers), erhalte ich die folgende Ausnahme:

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

Endgültige 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 für einen Server, der dieses Problem demonstriert, ist blend.esper.net:6697 (dies ist ein IRC Server). Ein Beispiel für einen Server, der das Problem nicht demonstriert, ist kornbluth.freenode. net: 6697. [Es überrascht nicht, dass alle Server in jedem Netzwerk dasselbe Verhalten haben.]

Mein Code (der, wie bereits erwähnt, beim Herstellen einer Verbindung zu einigen SSL-Servern funktioniert) lautet:

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

Es ist das letzte startHandshake, das die Ausnahme auslöst. Und ja, mit den 'trustAllCerts' ist etwas Magisches los; Dieser Code zwingt das SSL-System, Zertifikate nicht zu validieren. (Also ... kein Problem.)

Offensichtlich ist eine Möglichkeit, dass der Server von esper falsch konfiguriert ist, aber ich habe nach anderen Verweisen auf Personen gesucht und keine gefunden, die Probleme mit den SSL-Ports von esper haben, und 'openssl' stellt eine Verbindung dazu her (siehe unten). Ich frage mich also, ob dies eine Einschränkung der Java Standard-SSL-Unterstützung ist oder so. Irgendwelche Vorschläge?

Folgendes passiert, wenn ich mit 'openssl' von der Kommandozeile aus eine Verbindung zu blend.esper.net 6697 herstelle:

~ $ 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/[email protected]
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/[email protected]
verify return:1
---
Certificate chain
 0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
   i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]t
---
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/[email protected]
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
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, wird die Verbindung dennoch erfolgreich hergestellt, was mehr ist, als Sie für meine Java App sagen können.

Sollte es relevant sein, verwende ich OS X 10.6.8, Java Version 1.6.0_26.

135
sam

Das Problem ist die Primzahl. Die maximal zulässige Größe, die Java akzeptiert, ist 1024 Bit. Dies ist ein bekanntes Problem (siehe JDK-6521495 ).

Der Fehlerbericht, den ich verlinkt habe, erwähnt eine Problemumgehung mit BouncyCastles JCE-Implementierung. Hoffentlich sollte das für Sie funktionieren.

[~ # ~] Update [~ # ~]

Dies wurde als Bug JDK-704406 gemeldet und kürzlich behoben.

Beachten Sie jedoch, dass das Limit nur auf 2048 Bit erhöht wurde. Für Größen> 2048 Bit gibt es JDK-8072452 - Entfernen der maximalen Primzahlgröße von DH-Schlüsseln ; Der Fix scheint für 9 zu sein.

112
Vivin Paliath

Die Antwort "JCE (Java Cryptography Extension) Unlimited Strength Jurisdiction Policy Files" funktionierte nicht für mich, aber der Vorschlag des JCE-Anbieters von BouncyCastle.

Hier sind die Schritte, die ich mit Java 1.6.0_65-b14-462 unter Mac OSC 10.7.5 unternommen habe

1) Laden Sie diese Gläser herunter:

2) Verschieben Sie diese Gläser nach $ Java_HOME/lib/ext

3) Bearbeiten Sie $ Java_HOME/lib/security/Java.security wie folgt: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider

starten Sie die App mit JRE neu und probieren Sie es aus

67
mjj1409

Hier ist meine Lösung (Java 1.6), auch würde mich interessieren, warum ich das tun musste:

Aus javax.security.debug = ssl ist mir aufgefallen, dass die verwendete Verschlüsselungssuite manchmal TLS_DHE _... und manchmal TLS_ECDHE _.... ist. Letzteres würde passieren, wenn ich BouncyCastle hinzufüge. Wenn TLS_ECDHE_ ausgewählt wurde, funktionierte dies meistens, aber nicht IMMER. Daher war das Hinzufügen von BouncyCastle-Anbietern unzuverlässig (diesmal fehlgeschlagen, mit demselben Fehler). Ich vermute, irgendwo in der Sun SSL-Implementierung wird manchmal DHE gewählt, manchmal ECDHE =.

Die hier veröffentlichte Lösung basiert auf dem vollständigen Entfernen von TLS_DHE_-Chiffren. HINWEIS: BouncyCastle wird für die Lösung NICHT benötigt.

So erstellen Sie die Server-Zertifizierungsdatei:

echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Speichern Sie dies, da später darauf verwiesen wird, da hier die Lösung für ein SSL-HTTP-Get ohne die TLS_DHE_-Chiffresuiten angegeben ist.

package org.example.security;

import Java.io.BufferedInputStream;
import Java.io.BufferedReader;
import Java.io.FileInputStream;
import Java.io.IOException;
import Java.io.InputStream;
import Java.io.InputStreamReader;
import Java.net.InetAddress;
import Java.net.Socket;
import Java.net.URL;
import Java.net.UnknownHostException;
import Java.security.KeyStore;
import Java.security.cert.Certificate;
import Java.security.cert.CertificateFactory;
import Java.security.cert.X509Certificate;
import Java.util.ArrayList;
import Java.util.List;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManagerFactory;

import org.Apache.log4j.Logger;

public class SSLExcludeCipherConnectionHelper {

    private Logger logger = Logger.getLogger(SSLExcludeCipherConnectionHelper.class);

    private String[] exludedCipherSuites = {"_DHE_","_DH_"};

    private String trustCert = null;

    private TrustManagerFactory tmf;

    public void setExludedCipherSuites(String[] exludedCipherSuites) {
        this.exludedCipherSuites = exludedCipherSuites;
    }

    public SSLExcludeCipherConnectionHelper(String trustCert) {
        super();
        this.trustCert = trustCert;
        //Security.addProvider(new BouncyCastleProvider());
        try {
            this.initTrustManager();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private void initTrustManager() throws Exception {
        CertificateFactory cf = CertificateFactory.getInstance("X.509");
        InputStream caInput = new BufferedInputStream(new FileInputStream(trustCert));
        Certificate ca = null;
        try {
            ca = cf.generateCertificate(caInput);
            logger.debug("ca=" + ((X509Certificate) ca).getSubjectDN());
        } finally {
            caInput.close();
        }

        // Create a KeyStore containing our trusted CAs
        KeyStore keyStore = KeyStore.getInstance("jks");
        keyStore.load(null, null);
        keyStore.setCertificateEntry("ca", ca);

        // Create a TrustManager that trusts the CAs in our KeyStore
        String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
        tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
        tmf.init(keyStore);
    }

    public String get(URL url) throws Exception {
        // Create an SSLContext that uses our TrustManager
        SSLContext context = SSLContext.getInstance("TLS");
        context.init(null, tmf.getTrustManagers(), null);
        SSLParameters params = context.getSupportedSSLParameters();
        List<String> enabledCiphers = new ArrayList<String>();
        for (String cipher : params.getCipherSuites()) {
            boolean exclude = false;
            if (exludedCipherSuites != null) {
                for (int i=0; i<exludedCipherSuites.length && !exclude; i++) {
                    exclude = cipher.indexOf(exludedCipherSuites[i]) >= 0;
                }
            }
            if (!exclude) {
                enabledCiphers.add(cipher);
            }
        }
        String[] cArray = new String[enabledCiphers.size()];
        enabledCiphers.toArray(cArray);

        // Tell the URLConnection to use a SocketFactory from our SSLContext
        HttpsURLConnection urlConnection =
            (HttpsURLConnection)url.openConnection();
        SSLSocketFactory sf = context.getSocketFactory();
        sf = new DOSSLSocketFactory(sf, cArray);
        urlConnection.setSSLSocketFactory(sf);
        BufferedReader in = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
        String inputLine;
        StringBuffer buffer = new StringBuffer();
        while ((inputLine = in.readLine()) != null) 
            buffer.append(inputLine);
        in.close();

        return buffer.toString();
    }

    private class DOSSLSocketFactory extends javax.net.ssl.SSLSocketFactory {

        private SSLSocketFactory sf = null;
        private String[] enabledCiphers = null;

        private DOSSLSocketFactory(SSLSocketFactory sf, String[] enabledCiphers) {
            super();
            this.sf = sf;
            this.enabledCiphers = enabledCiphers;
        }

        private Socket getSocketWithEnabledCiphers(Socket socket) {
            if (enabledCiphers != null && socket != null && socket instanceof SSLSocket)
                ((SSLSocket)socket).setEnabledCipherSuites(enabledCiphers);

            return socket;
        }

        @Override
        public Socket createSocket(Socket s, String Host, int port,
                boolean autoClose) throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(s, Host, port, autoClose));
        }

        @Override
        public String[] getDefaultCipherSuites() {
            return sf.getDefaultCipherSuites();
        }

        @Override
        public String[] getSupportedCipherSuites() {
            if (enabledCiphers == null)
                return sf.getSupportedCipherSuites();
            else
                return enabledCiphers;
        }

        @Override
        public Socket createSocket(String Host, int port) throws IOException,
                UnknownHostException {
            return getSocketWithEnabledCiphers(sf.createSocket(Host, port));
        }

        @Override
        public Socket createSocket(InetAddress address, int port)
                throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(address, port));
        }

        @Override
        public Socket createSocket(String Host, int port, InetAddress localAddress,
                int localPort) throws IOException, UnknownHostException {
            return getSocketWithEnabledCiphers(sf.createSocket(Host, port, localAddress, localPort));
        }

        @Override
        public Socket createSocket(InetAddress address, int port,
                InetAddress localaddress, int localport) throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(address, port, localaddress, localport));
        }

    }
}

Zum Schluss erfahren Sie, wie es verwendet wird (certFilePath, wenn der Pfad des Zertifikats von openssl gespeichert wurde):

try {
            URL url = new URL("https://www.example.org?q=somedata");            
            SSLExcludeCipherConnectionHelper sslExclHelper = new SSLExcludeCipherConnectionHelper(certFilePath);
            logger.debug(
                    sslExclHelper.get(url)
            );
        } catch (Exception ex) {
            ex.printStackTrace();
        }
15
Zsozso

Die obige Antwort ist richtig, aber in Bezug auf die Problemumgehung hatte ich Probleme mit der BouncyCastle-Implementierung, als ich sie als bevorzugten Anbieter festgelegt habe:

Java.lang.ArrayIndexOutOfBoundsException: 64
    at com.Sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)

Dies wird auch in einem von mir gefundenen Forenthread besprochen, in dem es keine Lösung gibt. http://www.javakb.com/Uwe/Forum.aspx/Java-programmer/47512/TLS-problems

Ich habe eine alternative Lösung gefunden, die für meinen Fall funktioniert, obwohl ich damit überhaupt nicht zufrieden bin. Die Lösung besteht darin, es so einzustellen, dass der Diffie-Hellman-Algorithmus überhaupt nicht verfügbar ist. Angenommen, der Server unterstützt einen alternativen Algorithmus, wird dieser während der normalen Aushandlung ausgewählt. Dies hat natürlich den Nachteil, dass, wenn es jemandem irgendwie gelingt, einen Server zu finden, der Diffie-Hellman nur mit 1024 Bit oder weniger unterstützt, dies tatsächlich bedeutet, dass er dort nicht funktioniert, wo er früher funktioniert hat.

Hier ist Code, der mit einem SSLSocket funktioniert (bevor Sie ihn verbinden):

List<String> limited = new LinkedList<String>();
for(String suite : ((SSLSocket)s).getEnabledCipherSuites())
{
    if(!suite.contains("_DHE_"))
    {
        limited.add(suite);
    }
}
((SSLSocket)s).setEnabledCipherSuites(limited.toArray(
    new String[limited.size()]));

Böse.

13
sam

Sie können DHE in Ihrem jdk vollständig deaktivieren, jre/lib/security/Java.security bearbeiten und sicherstellen, dass DHE deaktiviert ist, z. mögen

jdk.tls.disabledAlgorithms=SSLv3, DHE.

12
Tor

Sie können den Provider dynamisch installieren:

1) Laden Sie diese Gläser herunter:

  • bcprov-jdk15on-152.jar
  • bcprov-ext-jdk15on-152.jar

2) Kopiere die Gläser nach WEB-INF/lib (Oder in deinen Klassenpfad)

3) Provider dynamisch hinzufügen:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

...

Security.addProvider(new BouncyCastleProvider());

12
angelcorral

Dies ist ein ziemlich alter Beitrag, aber wenn Sie Apache HTTPD verwenden, können Sie die DH-Größe begrenzen. Siehe http://httpd.Apache.org/docs/current/ssl/ssl_faq.html#javadh

7
Bertl

Wenn Sie jdk1.7.0_04 verwenden, aktualisieren Sie auf jdk1.7.0_21. Das Problem wurde in diesem Update behoben.

6
Lekkie

Versuchen Sie, "JCE-Richtliniendateien (Java Cryptography Extension, Java-Kryptografieerweiterung) mit unbeschränkter Stärke" von der Java-Download-Site herunterzuladen und die Dateien in Ihrer JRE zu ersetzen.

Dies funktionierte für mich und ich musste nicht einmal BouncyCastle verwenden - die standardmäßige Sun JCE konnte eine Verbindung zum Server herstellen.

PS. Ich habe den gleichen Fehler (ArrayIndexOutOfBoundsException: 64) erhalten, als ich vor dem Ändern der Richtliniendateien versucht habe, BouncyCastle zu verwenden. Unsere Situation scheint also sehr ähnlich zu sein.

5
mjomble

Wenn Sie immer noch von diesem Problem [~ # ~] und [~ # ~] gebissen werden, verwenden Sie Apache httpd v> 2.4.7, versuchen Sie dies : http://httpd.Apache.org/docs/current/ssl/ssl_faq.html#javadh

kopiert von der URL :

Ab Version 2.4.7 verwendet mod_ssl DH-Parameter, die Primzahlen mit einer Länge von mehr als 1024 Bit enthalten. Java 7 und früher beschränken ihre Unterstützung für DH-Primzahlen jedoch auf maximal 1024 Bit.

Wenn Ihr Java-basierter Client mit Ausnahmen wie Java.lang.RuntimeException abgebrochen wird: DH-Schlüsselpaar und Java.security.InvalidAlgorithmParameterException konnten nicht generiert werden: Die Primärgröße muss ein Vielfaches von 64 sein und kann nur zwischen 512 und 1024 (einschließlich) liegen httpd logs tlsv1 alarm interner Fehler (SSL-Alarmnummer 80) (bei LogLevel-Info oder höher), Sie können entweder die Verschlüsselungsliste von mod_ssl mit SSLCipherSuite neu anordnen (möglicherweise in Verbindung mit SSLHonorCipherOrder), oder Sie können benutzerdefinierte DH-Parameter mit einer 1024-Bit-Primzahl verwenden , die immer Vorrang vor den eingebauten DH-Parametern haben.

Verwenden Sie die Taste, um benutzerdefinierte DH-Parameter zu generieren

openssl dhparam 1024

befehl. Alternativ können Sie die folgenden Standard-1024-Bit-DH-Parameter aus RFC 2409, Abschnitt 6.2 verwenden:

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

Fügen Sie die benutzerdefinierten Parameter einschließlich der Zeilen "BEGIN DH PARAMETERS" und "END DH PARAMETERS" am Ende der ersten Zertifikatdatei hinzu, die Sie mit der Anweisung SSLCertificateFile konfiguriert haben.


Ich verwende Java 1.6 auf Client-Seite, und es hat mein Problem gelöst. Ich habe die Cipher Suites oder Ähnliches nicht gesenkt, sondern der cert-Datei einen benutzerdefinierten DH-Parameter hinzugefügt.

5
pka

Möglicherweise haben Sie falsche Maven-Abhängigkeiten. Sie müssen diese Bibliotheken in der Maven-Abhängigkeitshierarchie finden:

bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14

Wenn Sie diese Abhängigkeiten haben, ist das der Fehler, und Sie sollten dies tun:

Fügen Sie die Abhängigkeit hinzu:

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcmail-jdk15on</artifactId>
    <version>1.59</version>
</dependency>

Schließen Sie diese Abhängigkeiten von dem Artefakt aus, das die falschen Abhängigkeiten enthielt. In meinem Fall ist dies:

<dependency>
    <groupId>com.lowagie</groupId>
    <artifactId>itext</artifactId>
    <version>2.1.7</version>
    <exclusions>
        <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bctsp-jdk14</artifactId>                
        </exclusion>
        <exclusion>
            <groupId>bouncycastle</groupId>
            <artifactId>bcprov-jdk14</artifactId>               
        </exclusion>
        <exclusion>
            <groupId>bouncycastle</groupId>
            <artifactId>bcmail-jdk14</artifactId>               
        </exclusion>
    </exclusions>       
</dependency>

Ich habe das gleiche Problem mit Yandex Maps Server, JDK 1.6 und Apache HttpClient 4.2.1. Der Fehler war

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

bei aktiviertem Debug durch -Djavax.net.debug=all war eine Meldung in einem Protokoll

Could not generate DH keypair

Ich habe dieses Problem behoben, indem ich die BouncyCastle-Bibliothek bcprov-jdk16-1.46.jar Hinzugefügt und einen Anbieter in einer Kartendienstklasse registriert habe

public class MapService {

    static {
        Security.addProvider(new BouncyCastleProvider());
    }

    public GeocodeResult geocode() {

    }

}

Ein Anbieter ist bei der ersten Nutzung von MapService registriert.

2
v.ladynev

Ich benutze ColdFusion 8 auf JDK 1.6.45 und hatte Probleme damit, mir nur rote Kreuze anstelle von Bildern zu geben, und auch mit cfhttp, das mit SSL keine Verbindung zum lokalen Webserver herstellen kann.

mein test skript zum reproduzieren mit coldfusion 8 war

<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">

dies gab mir den ziemlich allgemeinen Fehler "E/A-Ausnahme: Peer nicht authentifiziert". Ich habe dann versucht, Zertifikate des Servers, einschließlich Stamm- und Zwischenzertifikate, zum Java= Keystore und auch zum Coldfusion-Keystore hinzuzufügen, aber nichts hat geholfen. Dann habe ich das Problem mit debuggt

Java SSLPoke www.onlineumfragen.com 443

und bekam

javax.net.ssl.SSLException: Java.lang.RuntimeException: Could not generate DH keypair

und

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:107)
    ... 10 more

Ich kam dann auf die Idee, dass der Webserver (in meinem Fall Apache) sehr moderne Verschlüsselungen für ssl hat und ziemlich restriktiv ist (qualys score a +) und starke diffie hellmann-Schlüssel mit mehr als 1024 Bit verwendet. Es ist offensichtlich, dass ColdFusion und Java jdk 1.6.45 dies nicht bewältigen können. Der nächste Schritt auf dem odysee bestand darin, einen alternativen Sicherheitsanbieter für Java zu installieren, 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 habe mir dann das runtergeladen

bcprov-ext-jdk15on-156.jar

from http://www.bouncycastle.org/latest_releases.html und installiert es unter C:\jdk6_45\jre\lib\ext oder wo immer sich Ihr JDK befindet, in der ursprünglichen Installation von ColdFusion 8 würde es Befindet sich unter C:\JRun4\jre\lib\ext, aber ich verwende ein neueres jdk (1.6.45), das sich außerhalb des ColdFusion-Verzeichnisses befindet. Es ist sehr wichtig, dass die Datei bcprov-ext-jdk15on-156.jar im Verzeichnis\ext abgelegt wird (das hat mich ungefähr zwei Stunden und ein paar Haare gekostet ;-). Dann habe ich die Datei C:\jdk6_45\jre\lib\security\bearbeitet. Java.security (mit wordpad nicht mit editor.exe!) Und für den neuen Provider in eine Zeile setzen. danach sah die Liste so aus

#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=Sun.security.provider.Sun
security.provider.3=Sun.security.rsa.SunRsaSign
security.provider.4=com.Sun.net.ssl.internal.ssl.Provider
security.provider.5=com.Sun.crypto.provider.SunJCE
security.provider.6=Sun.security.jgss.SunProvider
security.provider.7=com.Sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=Sun.security.smartcardio.SunPCSC
security.provider.10=Sun.security.mscapi.SunMSCAPI

(siehe die neue in Position 1)

starten Sie dann den ColdFusion-Dienst vollständig neu. du kannst dann

Java SSLPoke www.onlineumfragen.com 443 (or of course your url!)

und genieße das Gefühl ... und natürlich

was für eine Nacht und was für ein Tag. Hoffentlich hilft dies (teilweise oder vollständig) jemandem da draußen. Wenn Sie Fragen haben, senden Sie mir einfach eine E-Mail an info ... (Domain oben).

1
Raffael Meier

Ich habe den SSL-Fehler auf einem CentOS-Server mit JDK 6 festgestellt.

Mein Plan war, eine höhere JDK-Version (JDK 7) neben JDK 6 zu installieren, aber es stellte sich heraus, dass die bloße Installation des neueren JDK mit rpm -i Nicht ausreichte.

Die Installation von JDK 7 würde nur mit der Upgrade-Option rpm -U Erfolgreich sein, wie unten dargestellt.

1. Laden Sie JDK 7 herunter

wget -O /root/jdk-7u79-linux-x64.rpm --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.Oracle.com%2F; o raclelicense=accept-securebackup-cookie" "http://download.Oracle.com/otn-pub/Java/jdk/7u79-b15/jdk-7u79-linux-x64.rpm"

2. Die RPM-Installation schlägt fehl

rpm -ivh jdk-7u79-linux-x64.rpm
Preparing...                ########################################### [100%]
        file /etc/init.d/jexec from install of jdk-2000:1.7.0_79-fcs.x86_64 conflicts with file from package jdk-2000:1.6.0_43-fcs.x86_64

3. RPM-Upgrade erfolgreich

rpm -Uvh jdk-7u79-linux-x64.rpm
Preparing...                ########################################### [100%]
   1:jdk                    ########################################### [100%]
Unpacking JAR files...
        rt.jar...
        jsse.jar...
        charsets.jar...
        tools.jar...
        localedata.jar...
        jfxrt.jar...

4. Bestätigen Sie die neue Version

Java -version
Java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
1
Saheed

Das Problem wurde durch ein Upgrade auf JDK 8 behoben.

1
anre

Wir haben den gleichen exakten Ausnahmefehler zurückerhalten, der nach stundenlangem Surfen im Internet behoben werden konnte.

Wir haben die höchste Version von jdk heruntergeladen, die wir auf Oracle.com finden konnten, es installiert und den Jboss-Anwendungsserver auf das Verzeichnis des installierten neuen jdk verwiesen.

Jboss neu gestartet, aufbereitet, Problem behoben !!!

0

Ich habe einen ähnlichen Fehler beim Zugriff auf svn.Apache.org mit Java= SVN-Clients unter Verwendung eines IBM JDK erhalten. Derzeit verwenden svn.Apache.org-Benutzer die Client-Verschlüsselungseinstellungen.

Nachdem ich nur einmal mit einer Paketerfassung/javax.net.debug = ALL ausgeführt hatte, konnte ich nur eine einzige DHE-Verschlüsselung auf die Blacklist setzen, und die Dinge funktionieren für mich (ECDHE wird stattdessen ausgehandelt).

.../Java/jre/lib/security/Java.security:
    jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA

Eine nette schnelle Lösung, wenn es nicht einfach ist, den Client zu wechseln.

0
covener

Vor kurzem habe ich das gleiche Problem und nach dem Upgrade der jdk-Version von 1.6.0_45 auf jdk1.7.0_191, wodurch das Problem behoben wurde.

0
Sam

Ich habe diesen Fehler mit Bamboo 5.7 + Gradle-Projekt + Apache. Gradle hat versucht, einige Abhängigkeiten von einem unserer Server über SSL abzurufen.

Lösung:

  1. DH-Parameter generieren:

mit OpenSSL:

openssl dhparam 1024

beispielausgabe:

-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----
  1. Ausgabe an Zertifikatdatei anhängen (für Apache - SSLCertificateFile param)

  2. Starten Sie Apache neu

  3. Starten Sie Bamboo neu

  4. Versuchen Sie erneut, das Projekt zu erstellen

0
Evgeny Lebedev

Wenn der Server eine Verschlüsselung ohne DH unterstützt, können Sie den Client zwingen, diese Verschlüsselung auszuwählen und den DH-Fehler zu vermeiden. Sowie:

String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);

Denken Sie daran, dass die Angabe einer genauen Chiffre auf lange Sicht zum Bruch neigt.

0
Jason Martin