Perché l'handshake SSL dà l'eccezione "Impossibile generare la coppia di chiavi DH"?

Quando creo una connessione SSL con alcuni server IRC (ma non altri - presumibilmente a causa del metodo di crittografia preferito del server) ottengo la seguente eccezione:

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

Causa finale:

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

Un esempio di un server che dimostra questo problema è apertura.esper.net:6697 (questo è un server IRC). Un esempio di un server che non dimostra il problema è kornbluth.freenode.net:6697. [Non sorprende che tutti i server su ciascuna rete condividano lo stesso comportamento rispettivo.]

Il mio codice (che come indicato funziona quando ci si collega ad alcuni server SSL) è:

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

È l'ultimo avvio Handhake che genera l'eccezione. E sì, c'è un po 'di magia in corso con il' trustAllCerts '; quel codice impone al sistema SSL di non convalidare certificati. (Quindi ... non è un problema cert.)

Ovviamente una possibilità è che il server di esper sia configurato male, ma ho cercato e non ho trovato altri riferimenti a persone che hanno problemi con le porte SSL di esper, e 'openssl' si collega ad esso (vedi sotto). Quindi mi chiedo se questa è una limitazione del supporto SSL predefinito Java, o qualcosa del genere. Eventuali suggerimenti?

Ecco cosa succede quando mi collego a aperture.esper.net 6697 usando 'openssl' dalla riga di comando:

~ $ 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)
---

Come notato, dopo tutto, si collega correttamente, il che è più di quanto si possa dire per la mia app Java.

Se è pertinente, sto usando OS X 10.6.8, versione Java 1.6.0_26.

Il problema è la dimensione principale. La dimensione massima accettabile che Java accetta è 1024 bit. Questo è un problema noto (vedere JDK-6521495 ).

La segnalazione di bug a cui ho collegato menziona una soluzione utilizzando l'implementazione JCE di BouncyCastle. Spero che dovrebbe funzionare per te.

AGGIORNARE

Questo è stato segnalato come bug JDK-7044060 e corretto di recente.

Si noti, tuttavia, che il limite è stato aumentato solo a 2048 bit. Per dimensioni> 2048 bit, è presente JDK-8072452 - Rimuovere la dimensione massima massima delle chiavi DH ; la correzione sembra essere per 9.

La risposta "File di criteri di giurisdizione di forza illimitata di Java Cryptography Extension (JCE)" non ha funzionato per me, ma il suggerimento del provider JCE di BouncyCastle ha funzionato.

Ecco i passi che ho fatto usando Java 1.6.0_65-b14-462 su Mac OSC 10.7.5

1) Scarica questi vasi:

• bcprov-jdk15on-154.jar

• bcprov-ext-jdk15on-154.jar

2) sposta questi vasetti su $ JAVA_HOME / lib / ext

3) modifica $ JAVA_HOME / lib / security / java.security come segue: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider

riavvia l'app utilizzando JRE e provala

Ecco la mia soluzione (java 1.6), inoltre sarei interessato al motivo per cui ho dovuto fare questo:

Ho notato da javax.security.debug = ssl che a volte la suite di cifratura usata è TLS_DHE _... e qualche volta è TLS_ECDHE _.... Il successivo accadrebbe se aggiungessi BouncyCastle. Se è stato selezionato TLS_ECDHE_, la maggior parte delle volte ha funzionato, ma NON SEMPRE, quindi l'aggiunta anche del provider BouncyCastle è stata inaffidabile (non riuscita con lo stesso errore, ogni altra volta circa). Immagino che da qualche parte nell'implementazione di Sun SSL a volte scelga DHE , a volte scelga ECDHE .

Quindi la soluzione pubblicata qui si basa sulla rimozione completa delle cifre TLS_DHE_. NOTA: BouncyCastle NON è richiesto per la soluzione.

Quindi crea il file di certificazione del server:

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

Salvalo come verrà fatto riferimento in seguito, quindi ecco la soluzione per ottenere un HTTP http get, escluse le suite di crittografia TLS_DHE_.

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

    }
}

Infine ecco come viene utilizzato (certFilePath se il percorso del certificato salvato da openssl):

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

La risposta sopra è corretta, ma in termini di soluzione alternativa, ho riscontrato problemi con l'implementazione di BouncyCastle quando l'ho impostata come provider preferito:

java.lang.ArrayIndexOutOfBoundsException: 64
    at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)

Questo è anche discusso in un thread del forum che ho trovato, che non menziona una soluzione. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Ho trovato una soluzione alternativa che funziona per il mio caso, anche se non ne sono affatto contento. La soluzione è di impostarlo in modo tale che l'algoritmo Diffie-Hellman non sia affatto disponibile. Quindi, supponendo che il server supporti un algoritmo alternativo, verrà selezionato durante la normale negoziazione. Ovviamente il rovescio della medaglia di questo è che se qualcuno in qualche modo riesce a trovare un server che supporta Diffie-Hellman solo a 1024 bit o meno, ciò significa che in realtà non funzionerà dove prima funzionava.

Ecco il codice che funziona con un SSLSocket (prima di connetterlo):

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

Cattiva.

Puoi disabilitare completamente DHE nel tuo jdk, modificare jre / lib / security / java.security e assicurarti che DHE sia disabilitato, ad es. piace

jdk.tls.disabledAlgorithms=SSLv3, DHE.

È possibile installare il provider in modo dinamico:

1) Scarica questi vasi:

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

2) Copia i vasetti nel WEB-INF/lib(o nel tuo percorso di classe)

3) Aggiungi fornitore dinamicamente:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

...

Security.addProvider(new BouncyCastleProvider());

Questo è un post piuttosto vecchio, ma se usi Apache HTTPD, puoi limitare la dimensione del DH. Vedi http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Se si utilizza jdk1.7.0_04, eseguire l'aggiornamento a jdk1.7.0_21. Il problema è stato risolto in quell'aggiornamento.

È possibile che tu abbia dipendenze Maven errate. È necessario trovare queste librerie nella gerarchia delle dipendenze di Maven:

bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14

Se hai queste dipendenze che è l'errore, e dovresti fare questo:

Aggiungi la dipendenza:

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

Escludere queste dipendenze dal manufatto che includeva dipendenze errate, nel mio caso è:

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

Prova a scaricare "File delle norme sulla giurisdizione illimitata JCE (Java Cryptography Extension)" dal sito di download di Java e a sostituire i file nel tuo JRE.

Questo ha funzionato per me e non ho nemmeno avuto bisogno di usare BouncyCastle: lo standard Sun JCE era in grado di connettersi al server.

PS. Ho avuto lo stesso errore (ArrayIndexOutOfBoundsException: 64) quando ho provato a utilizzare BouncyCastle prima di modificare i file delle politiche, quindi sembra che la nostra situazione sia molto simile.

Se sei ancora morso da questo problema E stai utilizzando Apache httpd v> 2.4.7, prova questo: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

copiato dall'URL :

A partire dalla versione 2.4.7, mod_ssl utilizzerà i parametri DH che includono numeri primi con lunghezze superiori a 1024 bit. Java 7 e precedenti limitano il loro supporto per le dimensioni prime DH a un massimo di 1024 bit.

Se il client basato su Java si interrompe con eccezioni come java.lang.RuntimeException: impossibile generare la coppia di chiavi DH e java.security.InvalidAlgorithmParameterException: la dimensione principale deve essere multipla di 64 e può variare solo da 512 a 1024 (incluso) e httpd logs errore interno di avviso tlsv1 (avviso SSL numero 80) (alle informazioni LogLevel o successive), è possibile riorganizzare l'elenco di cifratura di mod_ssl con SSLCipherSuite (possibilmente in combinazione con SSLHonorCipherOrder), oppure è possibile utilizzare parametri DH personalizzati con un prime 1024 bit , che avrà sempre la precedenza su uno qualsiasi dei parametri DH incorporati.

Per generare parametri DH personalizzati, utilizzare il

openssl dhparam 1024

comando. In alternativa, è possibile utilizzare i seguenti parametri DH a 1024 bit standard da RFC 2409, sezione 6.2:

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

Aggiungi i parametri personalizzati tra cui le righe "BEGIN DH PARAMETERS" e "END DH PARAMETERS" alla fine del primo file di certificato che hai configurato usando la direttiva SSLCertificateFile.

Sto usando Java 1.6 sul lato client e ho risolto il mio problema. Non ho abbassato le suite di crittografia o simili, ma ho aggiunto un parametro DH generato personalizzato al file cert ..

Ho lo stesso problema con il server Yandex Maps, JDK 1.6 e Apache HttpClient 4.2.1. L'errore è stato

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

con il debug abilitato -Djavax.net.debug=all c'era un messaggio in un registro

Could not generate DH keypair

Ho risolto questo problema aggiungendo la libreria BouncyCastle bcprov-jdk16-1.46.jare registrando un provider in una classe di servizio della mappa

public class MapService {

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

    public GeocodeResult geocode() {

    }

}

Un provider è registrato al primo utilizzo di MapService.

Ho riscontrato l'errore SSL su un server CentOS con JDK 6.

Il mio piano era quello di installare una versione JDK superiore (JDK 7) per coesistere con JDK 6 ma si scopre che semplicemente installare il JDK più recente con rpm -i non era sufficiente.

L'installazione di JDK 7 avrebbe avuto successo solo con rpm -U opzione di aggiornamento come illustrato di seguito.

1. Scarica JDK 7

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. L'installazione RPM non riesce

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. L'aggiornamento RPM ha esito positivo

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. Conferma la nuova versione

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)

Risolto il problema aggiornando a JDK 8.

Uso coldfusion 8 su JDK 1.6.45 e ho avuto problemi a darmi solo croci rosse anziché immagini, e anche con cfhttp non sono riuscito a connettermi al server web locale con ssl.

il mio script di test da riprodurre con coldfusion 8 era

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

questo mi ha dato l'errore piuttosto generico di "Eccezione I / O: peer non autenticato". Ho quindi provato ad aggiungere certificati del server inclusi i certificati root e intermedi al keystore java e anche al keystore coldfusion, ma nulla mi ha aiutato. quindi ho eseguito il debug del problema con

java SSLPoke www.onlineumfragen.com 443

e ottenuto

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

e

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

Ho quindi avuto l'idea che il server web (apache nel mio caso) avesse cifre molto moderne per ssl ed è piuttosto restrittivo (il punteggio qualys a +) e usa chiavi Hellmann diffie forti con più di 1024 bit. ovviamente, coldfusion e java jdk 1.6.45 non possono gestirlo. Il passo successivo nell'odissea è stato pensare all'installazione di un fornitore di sicurezza alternativo per Java, e ho deciso per il castello gonfiabile. vedi anche http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Ho quindi scaricato il

bcprov-ext-jdk15on-156.jar

da http://www.bouncycastle.org/latest_releases.html e installato in C: \ jdk6_45 \ jre \ lib \ ext o dovunque sia il tuo jdk, nell'installazione originale di coldfusion 8 sarebbe sotto C: \ JRun4 \ jre \ lib \ ext ma utilizzo un jdk più recente (1.6.45) situato all'esterno della directory coldfusion. è molto importante mettere bcprov-ext-jdk15on-156.jar nella directory \ ext (questo mi è costato circa due ore e alcuni capelli ;-) quindi ho modificato il file C: \ jdk6_45 \ jre \ lib \ security \ java.security (con wordpad non con editor.exe!) e messo in una riga per il nuovo provider. in seguito la lista sembrava

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

(vedi il nuovo in posizione 1)

quindi riavviare completamente il servizio di fusione fredda. allora puoi

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

e goditi la sensazione ... e ovviamente

che notte e che giorno. Spero che questo possa aiutare (parzialmente o completamente) a qualcuno là fuori. se hai domande, mandami una mail a info ... (dominio sopra).

Se il server supporta un codice che non include DH, è possibile forzare il client a selezionare quel codice ed evitare l'errore DH. Ad esempio:

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

Tieni presente che la specifica di un codice esatto è soggetta a rotture a lungo termine.

Abbiamo restituito lo stesso esatto errore di eccezione, per risolverlo è stato facile dopo ore navigando in Internet.

Abbiamo scaricato la versione più alta di jdk che abbiamo trovato su oracle.com, installato e indirizzato il server delle applicazioni Jboss nella directory del nuovo jdk installato.

Riavviato Jboss, rielaborato, problemo risolto !!!

Ho questo errore con Bamboo 5.7 + progetto Gradle + Apache. Gradle ha cercato di ottenere alcune dipendenze da uno dei nostri server tramite SSL.

Soluzione:

1. Genera DH Param:

con OpenSSL:

openssl dhparam 1024

esempio di output:

-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----

2. Aggiungi output al file del certificato (per Apache - SSLCertificateFileparam)

3. Riavvia apache

4. Riavvia Bamboo

5. Prova a costruire di nuovo il progetto

Ho avuto un errore simile accedendo a svn.apache.org con client SVN Java usando un IBM JDK. Attualmente, svn.apache.org utilizza le preferenze di cifratura dei client.

Dopo aver eseguito una sola volta con una cattura di pacchetti / javax.net.debug = ALL sono stato in grado di inserire nella blacklist solo un singolo codice DHE e le cose funzionano per me (invece viene negoziato ECDHE).

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

Una bella soluzione rapida quando non è facile cambiare il client.

Recentemente ho lo stesso problema e dopo aver aggiornato la versione jdk dalla 1.6.0_45 alla jdk1.7.0_191 che ha risolto il problema.

Per me, la seguente riga di comando ha risolto il problema:

java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true -Djavax.net.debug=ssl:handshake XXXXX.jar

Sto usando JDK 1.7.0_79