Почему рукопожатие 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();
Это последний стартовый толчок, который вызывает исключение. И да, с "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.
22 ответа
Проблема в простом размере. Максимально допустимый размер, который принимает Java, составляет 1024 бита. Это известная проблема (см. JDK-6521495).
В сообщении об ошибке, на которое я ссылался, упоминается обходной путь с использованием реализации JCE BouncyCastle. Надеюсь, это должно сработать для вас.
ОБНОВИТЬ
Это было сообщено как ошибка JDK-7044060 и недавно исправлено.
Обратите внимание, однако, что предел был увеличен только до 2048 бит. Для размеров> 2048 бит есть JDK-8072452 - Удалить максимальный основной размер ключей DH; исправление, кажется, для 9.
Ответ "Файлы политики неограниченной юрисдикции Java Cryptography Extension (JCE)" не сработал для меня, но предложение поставщика JCE от BouncyCastle сработало.
Вот шаги, которые я предпринял, используя Java 1.6.0_65-b14-462 на Mac OSC 10.7.5
1) Скачать эти банки:
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 было ненадежным (сбой с той же ошибкой, каждый раз или около того). Я предполагаю, что где-то в реализации SSL SSL иногда выбирают DHE, иногда выбирают ECDHE.
Поэтому решение, размещенное здесь, основано на полном удалении шифров TLS_DHE_. ПРИМЕЧАНИЕ: BouncyCastle НЕ требуется для решения.
Итак, создайте файл сертификации сервера:
echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
Сохраните это, так как на него будет ссылаться позже, чем здесь решение для HTTP 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();
}
Ответ выше верен, но с точки зрения обходного пути у меня были проблемы с реализацией 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
Я нашел альтернативное решение, которое работает для моего случая, хотя я совсем не доволен им. Решение состоит в том, чтобы установить его так, чтобы алгоритм Диффи-Хеллмана вообще не был доступен. Затем, предположив, что сервер поддерживает альтернативный алгоритм, он будет выбирать во время обычного согласования. Очевидно, что недостатком этого является то, что если кому-то каким-то образом удастся найти сервер, который поддерживает только Диффи-Хеллмана со скоростью 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.jarbcprov-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
Возможно, у вас неверные зависимости 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>
Если вы используете jdk1.7.0_04, обновитесь до jdk1.7.0_21. Проблема была исправлена в этом обновлении.
Попробуйте загрузить "Файлы политики неограниченной юрисдикции 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
скопировано с 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), чтобы сосуществовать с 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)
Я использую coldfusion 8 на JDK 1.6.45 и у меня были проблемы с тем, что вместо изображений я выделяю только красные крестики, а также с cfhttp, не способным подключиться к локальному веб-серверу с помощью ssl.
мой тестовый сценарий для воспроизведения с Coldfusion 8 был
<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">
это дало мне довольно общую ошибку " I/O Exception: peer not authenticated". Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей 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 Score a+) и использует сильные ключи 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 или где бы ни находился ваш 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)
затем полностью перезапустите сервис Coldfusion. Вы можете тогда
java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
и наслаждайся чувством... и конечно
какая ночь и какой день. Надеюсь, это поможет (частично или полностью) кому-то там. если у вас есть вопросы, просто напишите мне на info... (домен выше).
Недавно у меня возникла та же проблема, и после обновления версии jdk с 1.6.0_45 до jdk1.7.0_191, которая разрешила проблему.
Я получил эту ошибку с 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-----
Добавить вывод в файл сертификата (для Apache -
SSLCertificateFileпары)Перезапустите Apache
Перезагрузите бамбук
Попробуйте построить проект еще раз
Мы получили точно такую же ошибку исключения, чтобы исправить это было легко после нескольких часов серфинга в интернете.
Мы загрузили самую высокую версию jdk, которую мы могли найти на oracle.com, установили ее и указали сервер приложений Jboss в каталог установленного нового jdk.
Перезапущен Jboss, переработан, проблема исправлена !!!
Раньше я получал похожую ошибку при доступе к svn.apache.org с Java-клиентами Java с использованием 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
Хорошее быстрое исправление, когда изменить клиента нелегко.
Для меня следующая командная строка устранила проблему:
java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true
-Djavax.net.debug=ssl:handshake XXXXX.jar
Я использую JDK 1.7.0_79
Окно -> Настройки -> Java -> Установленные JRE -> выберите jre и отредактируйте. И в аргументах виртуальной машины по умолчанию введите
-Dcom.sun.net.ssl.enableECC=false
Нажмите Готово
Если сервер поддерживает шифр, который не включает DH, вы можете заставить клиента выбрать этот шифр и избежать ошибки DH. Такие как:
String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);
Имейте в виду, что указание точного шифра в долгосрочной перспективе может привести к поломке.