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

когда я делаю 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.Эспер.net: 6697 (это IRC-сервер). Примером сервера, который не демонстрирует проблему, является kornbluth.freenode.net: 6697. [Неудивительно, что все серверы в каждой сети совместно используют то же самое поведение.]

мой код (который, как отмечалось, работает при подключении к некоторым серверам SSL):

    SSLContext sslContext = SSLContext.getInstance("SSL");
    sslContext.init(null, trustAllCerts, new SecureRandom());
    s = (SSLSocket)sslContext.getSocketFactory().createSocket();
    s.connect(new InetSocketAddress(host, port), timeout);
    s.setSoTimeout(0);
    ((SSLSocket)s).startHandshake();

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

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

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

~ $ openssl s_client -connect aperture.esper.net:6697
CONNECTED(00000003)
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify return:1
---
Certificate chain
 0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
   i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
Server certificate
-----BEGIN CERTIFICATE-----
[There was a certificate here, but I deleted it to save space]
-----END CERTIFICATE-----
subject=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
No client certificate CA names sent
---
SSL handshake has read 2178 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 51F1D40A1B044700365D3BD1C61ABC745FB0C347A334E1410946DCB5EFE37AFD
    Session-ID-ctx: 
    Master-Key: DF8194F6A60B073E049C87284856B5561476315145B55E35811028C4D97F77696F676DB019BB6E271E9965F289A99083
    Key-Arg   : None
    Start Time: 1311801833
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

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

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

21 ответов


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

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

обновление

Это было сообщено как ошибка JDK-7044060 и недавно отремонтированы.

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


ответ" Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files " не работал для меня, но предложение поставщика JCE BouncyCastle сделало это.

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

1) Скачать эти баночки:

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

3) редактировать $JAVA_HOME / lib / безопасность / java.безопасность следующим образом: безопасность.поставщик.1=org.после установки BouncyCastle.око.поставщик.BouncyCastleProvider

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


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

Я заметил из javax.безопасность.debug=ssl, что иногда используемый набор шифров является tls_dhe_... и когда-нибудь это TLS_ECDHE_.... Позже произойдет, если я добавлю BouncyCastle. Если tls_ecdhe_ был выбран, большую часть времени он работал, но не всегда, поэтому добавление даже поставщика BouncyCastle было ненадежным (сбой с той же ошибкой, каждый раз или около того). Наверное, где-то на Солнце. реализация иногда его выбирают 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();
        }

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

jdk.tls.disabledAlgorithms=SSLv3, DHE.


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

1) Скачать эти баночки:

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

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

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, которые включают простые числа с длиной более 1024 бит. Однако Java 7 и более ранние версии ограничивают их поддержку простых размеров DH максимум 1024 битами.

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

для создания пользовательских параметров DH используйте

openssl dhparam 1024


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

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

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


у меня такая же проблема с Yandex Maps server, 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 library bcprov-jdk16-1.46.jar и регистрация провайдера в классе картографического сервиса

public class MapService {

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

    public GeocodeResult geocode() {

    }

}

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


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


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

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

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

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

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, и я решил для bouncy castle. см. также 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.банка в каталоге \ext (это стоило мне около двух часов и некоторых волос ;-) затем я отредактировал файл C:\jdk6_45\jre\lib\security\java - ... безопасность (с wordpad не с редактором.exe!) и поставить в одну строку для нового провайдера. после этого список выглядел так:

#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI

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

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

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

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

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


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

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

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


У нас точно такая же ошибка возвращается, чтобы исправить это было легко после нескольких часов серфинга в интернете.

мы загрузили самую высокую версию jdk, которую мы могли найти на oracle.com, установил его и указал JBoss application server в каталог установленного нового 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-----
  1. добавить вывод в файл сертификата (для Apache - SSLCertificateFile param)

  2. перезагрузка Апач

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

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


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

после запуска только один раз с захватом пакета / javax.сеть.debug=все, что я смог занести в черный список только один шифр 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 -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 -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

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

добавить зависимость:

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

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