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

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

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

ОБНОВИТЬ

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

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

«Ответ на вопрос о политике защиты от критической мозаики Java (JCE)« Неограниченная сила »не помог мне, но предложение провайдера BouncyCastle JCE сделало.

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

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

• bcprov-jdk15on-154.jar

• bcprov-доб-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_, 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 enabledCiphers = new ArrayList(); for (String cipher : params.getCipherSuites()) { boolean exclude = false; if (exludedCipherSuites != null) { for (int i=0; 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 limited = new LinkedList(); 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 (или ваш путь к classам)

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. Проблема была исправлена ​​в этом обновлении.

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

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

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

Если ваш Java-клиент прерывается с исключениями, такими как java.lang.RuntimeException: не удалось создать DH keypair и java.security.InvalidAlgorithmParameterException: размер Prime должен быть кратным 64 и может варьироваться от 512 до 1024 (включительно) и HTTPd logs 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.

Попробуйте загрузить “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” с сайта загрузки Java и заменить файлы в JRE.

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

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

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

 javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated 

с включенным debug от -Djavax.net.debug=all было сообщение в журнале

 Could not generate DH keypair 

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

 public class MapService { static { Security.addProvider(new BouncyCastleProvider()); } public GeocodeResult geocode() { } } 

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

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

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

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

это дало мне довольно общую ошибку в «Исключении ввода-вывода: равносильно аутентификации». Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей 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.(DHCrypt.java:107) ... 10 more 

Тогда у меня возникла идея, что веб-сервер (apache в моем случае) имеет очень современные шифры для ssl и является довольно ограничительным (qualys score 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 … (домен выше).

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

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

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

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

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

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

У меня эта ошибка с проектом Bamboo 5.7 + Gradle + 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 param)

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

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

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 

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

Я столкнулся с ошибкой 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) 

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

 bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14 

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

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

  org.bouncycastle bcmail-jdk15on 1.59  

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

  com.lowagie itext 2.1.7   org.bouncycastle bctsp-jdk14   bouncycastle bcprov-jdk14   bouncycastle bcmail-jdk14    

В последнее время у меня такая же проблема и после обновления версии 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