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

Ответ 1

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

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

UPDATE

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

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

Ответ 2

"Ответы на политику криминализации расширения (JCE)" Неограниченная сила "." Ответ не помог мне, но предложение провайдера BouncyCastle JCE сделало.

Вот шаги, которые я предпринял с использованием 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 и попробуйте

Ответ 3

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

Я заметил из javax.security.debug = ssl, что иногда используемый набор шифров - TLS_DHE _... и иногда это TLS_ECDHE _..... Позднее произойдет, если я добавлю BouncyCastle. Если выбрано TLS_ECDHE_, MOST OF the time it, но не ВСЕГДА, поэтому добавление даже провайдера 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 get, за исключением наборов шифрования 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();
        }

Ответ 4

Ответ выше правильный, но с точки зрения обходного пути у меня были проблемы с реализацией 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()]));

Насти.

Ответ 5

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

jdk.tls.disabledAlgorithms=SSLv3, DHE.

Ответ 6

Динамическую установку поставщика можно установить:

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

Если вы по-прежнему укушены этой проблемой и используете 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 в файл сертификата.

Ответ 11

Возможно, у вас неверные зависимости 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>

Ответ 12

У меня такая же проблема с сервером Yandex Maps, 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.

Ответ 13

Решена проблема, перейдя на JDK 8.

Ответ 14

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

мой тест script для воспроизведения с coldfusion 8 был

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

это дало мне довольно общую ошибку: "Исключение I/O: равноуровень не аутентифицирован". Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей 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 и является довольно ограничительным (qualys оценивает a +) и использует сильные ключи diffmann hellmann с более чем 1024 бит. очевидно, coldfusion и java jdk 1.6.45 не могут справиться с этим. Следующий шаг в одизее состоял в том, чтобы подумать об установке альтернативного поставщика безопасности для 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 или где-либо ваш jdk, в оригинальной установке 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)

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

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

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

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

Ответ 15

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

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

Установка 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)

Ответ 16

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

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

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

Ответ 17

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

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

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

Ответ 18

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

Решение:

• Сгенерировать 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 param)

3. Перезапустить apache

4. Перезапустить бамбук

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

Ответ 19

Я использовал для получения аналогичной ошибки доступ к 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

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

Ответ 20

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

Ответ 21

Ошибка является ограничением Java. Настройте провайдера JCE:

https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html

Ответ 22

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

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

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