Чому 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();

Виняток кидає саме останній старт Handshake. І так, з 'trustAllCerts' відбувається якась магія; цей код змушує систему SSL не перевіряти цертс. (Отже ... не проблема з сертом.)

Очевидно, одна з можливостей полягає в тому, що сервер esper неправильно налаштований, але я шукав і не знайшов жодних інших посилань на людей, які мають проблеми з SSL портами esper, і 'openssl' підключається до нього (див. Нижче). Тож мені цікаво, чи це обмеження підтримки Java SSL за замовчуванням, чи щось. Будь-які пропозиції?

Ось що відбувається, коли я підключаюсь до 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-криптографії (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 було недостовірним (не вдалося з тією ж помилкою, кожен інший раз або близько того). Я думаю, десь у впровадженні SS 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. Проблема була виправлена ​​в цьому оновлення.

Цілком можливо, що у вас неправильні залежності Мейвена. Ви повинні знайти ці бібліотеки в ієрархії залежності Мевена:

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 (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 використовуйте

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 до файлу cert ..

У мене така ж проблема з сервером Яндекс Карт, 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)

Вирішили проблему, перейшовши на JDK 8.

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

мій тестовий сценарій для відтворення за допомогою холодного синтезу 8 був

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

це дало мені досить загальну помилку "Виняток вводу / виводу: одноранговий не автентифікований". Потім я спробував додати сертифікати сервера, включаючи кореневі та проміжні сертифікати, до сховища ключів Java, а також сховища холодного злиття, але нічого не допомогло. потім я налагодив проблему

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 не можуть цим керувати. Наступним кроком одізея було подумати про встановлення альтернативного постачальника безпеки для 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, в оригінальній установці холодного терміну 8 він був би під C: \ JRun4 \ jre \ lib \ ext, але я використовую новіший jdk (1.6.45), розміщений за межами каталогу холодного синтезу. дуже важливо помістити 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!)

і насолоджуватися почуттям ... і звичайно

яка ніч і яка день. Сподіваємось, це допоможе (частково або повністю) комусь там. якщо у вас є запитання, просто напишіть мені по електронній пошті ... (домен вище).

Якщо сервер підтримує шифр, який не включає 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. Перезапустіть апаш

4. Перезавантажте бамбук

5. Спробуйте створити проект ще раз

Я раніше отримував аналогічну помилку під час доступу до svn.apache.org з клієнтами Java SVN за допомогою IBM JDK. В даний час, svn.apache.org користувачі шифрують налаштування клієнтів.

Після запуску лише один раз із захопленням пакетів / javax.net.debug = ВСЕ мені вдалося занести до чорного списку лише один шифр 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