Почему при подтверждении SSL возникает исключение «Не удалось создать пару ключей DH»?

Когда я устанавливаю SSL-соединение с некоторыми серверами IRC (но не с другими - предположительно из-за предпочтительного метода шифрования сервера), я получаю следующее исключение:

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

Конечная причина:

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

Примером сервера, демонстрирующего эту проблему, является aperture.esper.net:6697 (это сервер IRC). Примером сервера, который не демонстрирует проблему, является kornbluth.freenode.net:6697. [Неудивительно, что все серверы в каждой сети ведут себя одинаково.]

Мой код (который, как уже отмечалось, работает при подключении к некоторым серверам 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();

Это последний startHandshake, который вызывает исключение. И да, с trustAllCerts творится некое волшебство; этот код заставляет систему SSL не проверять сертификаты. (Так что ... это не проблема.)

Очевидно, одна из возможностей заключается в том, что сервер esper настроен неправильно, но я искал и не нашел никаких других ссылок на людей, у которых есть проблемы с портами SSL esper, и к нему подключается openssl (см. Ниже). Так что мне интересно, является ли это ограничением поддержки SSL по умолчанию Java или что-то в этом роде. Какие-либо предложения?

Вот что происходит, когда я подключаюсь к aperture.esper.net 6697 с помощью openssl из командной строки:

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

Как уже отмечалось, после всего этого он успешно подключается, что больше, чем вы можете сказать для моего приложения Java.

Если это актуально, я использую OS X 10.6.8, Java версии 1.6.0_26.

Проблема в простом размере. Максимально допустимый размер, который принимает Java, составляет 1024 бита. Это известная проблема (см. JDK-6521495 ).

В отчете об ошибке, на который я ссылался, упоминается обходной путь с использованием реализации JCE BouncyCastle. Надеюсь, это сработает для вас.

ОБНОВИТЬ

Об этом сообщалось как об ошибке JDK-7044060, и она была недавно исправлена.

Обратите внимание, однако, что предел был увеличен только до 2048 бит. Для размеров> 2048 бит есть JDK-8072452 - Удалить максимальный простой размер ключей DH ; исправление похоже на 9.

Ответ «Файлы политики юрисдикции с неограниченной надежностью расширения Java Cryptography (JCE)» не сработал для меня, но предложение поставщика JCE от BouncyCastle сработало.

Вот шаги, которые я предпринял, используя Java 1.6.0_65-b14-462 на Mac OSC 10.7.5.

1) Загрузите эти банки:

• bcprov-jdk15on-154.jar

• bcprov-ext-jdk15on-154.jar

2) переместите эти банки в $ JAVA_HOME / lib / ext

3) отредактируйте $ JAVA_HOME / lib / security / java.security следующим образом: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider

перезапустите приложение с помощью JRE и попробуйте

Вот мое решение (java 1.6), тоже было бы интересно, почему я должен был это сделать:

Я заметил из javax.security.debug = ssl, что иногда используемый набор шифров - это TLS_DHE _..., а иногда это TLS_ECDHE _..... Позднее произойдет, если я добавлю BouncyCastle. Если был выбран TLS_ECDHE_, БОЛЬШИНСТВО времени он работал, но не ВСЕГДА, поэтому добавление даже поставщика BouncyCastle было ненадежным (сбой с той же ошибкой, каждый раз или около того). Я предполагаю, что где-то в реализации Sun SSL иногда выбирается DHE , иногда ECDHE .

Таким образом, размещенное здесь решение основано на полном удалении шифров TLS_DHE_. ПРИМЕЧАНИЕ: BouncyCastle НЕ требуется для решения.

Итак, создайте файл сертификации сервера:

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

Сохраните это, поскольку на него будут ссылаться позже, чем будет решение для получения SSL http, за исключением наборов шифров 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));
        }

    }
}

Наконец, вот как он используется (certFilePath, если путь сертификата сохранен из 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();
        }

Приведенный выше ответ правильный, но с точки зрения обходного пути у меня возникли проблемы с реализацией BouncyCastle, когда я установил его в качестве предпочтительного поставщика:

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

Это также обсуждается в одной ветке форума, которую я нашел, в которой не упоминается решение. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Я нашел альтернативное решение, которое работает в моем случае, хотя оно меня совсем не устраивает. Решение состоит в том, чтобы настроить его так, чтобы алгоритм Диффи-Хеллмана был вообще недоступен. Затем, если сервер поддерживает альтернативный алгоритм, он будет выбран во время обычного согласования. Очевидно, обратная сторона этого состоит в том, что если кому-то каким-то образом удастся найти сервер, который поддерживает только Diffie-Hellman на 1024 битах или меньше, то это фактически означает, что он не будет работать там, где он работал раньше.

Вот код, который работает с SSLSocket (до его подключения):

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

Противно.

Вы можете полностью отключить DHE в своем jdk, отредактировать jre / lib / security / java.security и убедиться, что DHE отключен, например. подобно

jdk.tls.disabledAlgorithms=SSLv3, DHE.

Вы можете установить провайдера динамически:

1) Загрузите эти банки:

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

2) Скопируйте банки в WEB-INF/lib(или в ваш путь к классам)

3) Добавить провайдера динамически:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

...

Security.addProvider(new BouncyCastleProvider());

Это довольно старый пост, но если вы используете Apache HTTPD, вы можете ограничить размер DH. См. Http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Если вы используете jdk1.7.0_04, обновитесь до jdk1.7.0_21. В этом обновлении проблема исправлена.

Возможно, у вас неправильные зависимости Maven. Вы должны найти эти библиотеки в иерархии зависимостей Maven:

bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14

Если у вас есть эти зависимости, это ошибка, и вы должны сделать это:

Добавьте зависимость:

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

Исключите эти зависимости из артефакта, который включает неправильные зависимости, в моем случае это:

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

Попробуйте загрузить "Файлы политики юрисдикции неограниченной надежности Java Cryptography Extension (JCE)" с сайта загрузки Java. и заменить файлы в своей JRE.

У меня это сработало, и мне даже не пришлось использовать BouncyCastle - стандартный Sun JCE мог подключаться к серверу.

PS. У меня такая же ошибка (ArrayIndexOutOfBoundsException: 64), когда я пытался использовать BouncyCastle перед изменением файлов политики, поэтому, похоже, наша ситуация очень похожа.

Если вас все еще беспокоит эта проблема, И вы используете Apache httpd v> 2.4.7, попробуйте следующее: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

скопировано с URL :

Начиная с версии 2.4.7, mod_ssl будет использовать параметры DH, которые включают простые числа длиной более 1024 бит. Однако Java 7 и более ранние версии ограничивают поддержку простых размеров DH до 1024 бит.

Если ваш клиент на основе Java прерывает работу с такими исключениями, как java.lang.RuntimeException: не удалось сгенерировать пару ключей DH и java.security.InvalidAlgorithmParameterException: основной размер должен быть кратен 64 и может находиться в диапазоне от 512 до 1024 (включительно), и httpd регистрирует внутреннюю ошибку предупреждения tlsv1 (номер предупреждения SSL 80) (на уровне информации LogLevel или выше), вы можете изменить список шифров mod_ssl с помощью SSLCipherSuite (возможно, в сочетании с SSLHonorCipherOrder), или вы можете использовать настраиваемые параметры DH с 1024-битным простым числом , который всегда будет иметь приоритет над любым из встроенных параметров DH.

Чтобы сгенерировать специальные параметры DH, используйте

openssl dhparam 1024

команда. В качестве альтернативы вы можете использовать следующие стандартные 1024-битные параметры DH из RFC 2409, раздел 6.2:

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

Добавьте пользовательские параметры, включая строки «BEGIN DH PARAMETERS» и «END DH PARAMETERS», в конец первого файла сертификата, который вы настроили с помощью директивы SSLCertificateFile.

Я использую java 1.6 на стороне клиента, и это решило мою проблему. Я не понижал комплекты шифров и т.п., но добавил настраиваемый параметр DH в файл сертификата.

У меня такая же проблема с сервером Яндекс Карты, JDK 1.6 и Apache HttpClient 4.2.1. Ошибка была

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

при включенной отладке -Djavax.net.debug=all появилось сообщение в журнале

Could not generate DH keypair

Я исправил эту проблему, добавив библиотеку BouncyCastle bcprov-jdk16-1.46.jarи зарегистрировав поставщика в классе картографического сервиса.

public class MapService {

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

    public GeocodeResult geocode() {

    }

}

Провайдер регистрируется при первом использовании MapService.

Я столкнулся с ошибкой SSL на сервере CentOS с JDK 6.

Я планировал установить более высокую версию JDK (JDK 7), чтобы она rpm -iмогла сосуществовать с JDK 6, но оказалось, что простой установки более новой версии JDK было недостаточно.

Установка JDK 7 будет успешной только с rpm -Uопцией обновления, как показано ниже.

1. Загрузите 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. Установка RPM не выполняется.

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 выполнено успешно.

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. Подтвердите новую версию.

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)

Решил проблему обновлением до JDK 8.

Я использую coldfusion 8 на JDK 1.6.45, и у меня возникли проблемы с отображением только красных крестиков вместо изображений, а также с cfhttp, неспособным подключиться к локальному веб-серверу с помощью ssl.

мой тестовый сценарий для воспроизведения с помощью coldfusion 8 был

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

это дало мне довольно общую ошибку «Исключение ввода-вывода: одноранговый узел не аутентифицирован». Затем я попытался добавить сертификаты сервера, включая корневой и промежуточный сертификаты, в хранилище ключей java, а также в хранилище ключей coldfusion, но ничего не помогло. затем я отладил проблему с

java SSLPoke www.onlineumfragen.com 443

и получил

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

а также

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

Затем у меня возникла идея, что веб-сервер (в моем случае apache) имеет очень современные шифры для ssl и довольно ограничен (оценка качества +) и использует сильные ключи diffie hellmann с более чем 1024 битами. очевидно, Coldfusion и java jdk 1.6.45 не могут справиться с этим. Следующим шагом в odysee была мысль об установке альтернативного провайдера безопасности для java, и я выбрал надувной замок. смотрите также http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Затем я загрузил

bcprov-ext-jdk15on-156.jar

из http://www.bouncycastle.org/latest_releases.html и установил его в C: \ jdk6_45 \ jre \ lib \ ext или где-либо еще, в исходной установке coldfusion 8 он будет в C: \ JRun4 \ jre \ lib \ ext, но я использую более новый jdk (1.6.45), расположенный вне каталога coldfusion. очень важно поместить bcprov-ext-jdk15on-156.jar в каталог \ ext (это стоило мне около двух часов и немного волос ;-), затем я отредактировал файл C: \ jdk6_45 \ jre \ lib \ security \ java.security (с помощью wordpad, а не с editor.exe!) и поместите в одну строку для нового поставщика. потом список выглядел как

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

(см. новый в позиции 1)

затем полностью перезапустите службу coldfusion. тогда ты можешь

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

и наслаждайтесь ощущением ... и, конечно же

что за ночь и что за день. Надеюсь, это поможет (частично или полностью) кому-то там. если у вас есть вопросы, просто напишите мне по адресу info ... (домен выше).

Если сервер поддерживает шифр, который не включает DH, вы можете заставить клиента выбрать этот шифр и избежать ошибки DH. Такие как:

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

Имейте в виду, что указание точного шифра в конечном итоге может выйти из строя.

Мы получили ту же самую ошибку исключения, которую легко исправить после нескольких часов работы в Интернете.

Мы загрузили самую высокую версию jdk, которую смогли найти на oracle.com, установили ее и направили сервер приложений Jboss в каталог установленного нового jdk.

Jboss перезапущен, переработан, проблема исправлена ​​!!!

У меня эта ошибка с Bamboo 5.7 + Gradle project + Apache. Gradle попытался получить некоторые зависимости от одного из наших серверов через SSL.

Решение:

1. Создать DH Param:

с OpenSSL:

openssl dhparam 1024

пример вывода:

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

2. Добавить вывод в файл сертификата (для Apache - SSLCertificateFileпараметр)

3. Перезагрузите apache

4. Перезапустить Bamboo

5. Попробуй снова построить проект

Раньше я получал аналогичную ошибку при доступе к svn.apache.org с помощью клиентов java SVN с использованием IBM JDK. В настоящее время svn.apache.org использует настройки шифрования клиентов.

После однократного запуска с захватом пакетов / javax.net.debug = ALL я смог занести в черный список только один шифр DHE, и у меня все заработало (вместо этого согласовываются ECDHE).

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

Хорошее быстрое исправление, когда изменить клиента непросто.

Недавно у меня возникла такая же проблема, и после обновления версии jdk с 1.6.0_45 до jdk1.7.0_191, которая решила проблему.

Для меня следующая командная строка устранила проблему:

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

Я использую JDK 1.7.0_79