SSLハンドシェイクで「DHキーペアを生成できませんでした」という例外が発生するのはなぜですか？

一部のIRCサーバー（他のサーバーではない-おそらくサーバーの優先暗号化方式によるもの）とSSL接続を行うと、次の例外が発生します。

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

例外をスローするのはその最後のstartHandshakeです。そして、はい、 'trustAllCerts'には魔法がかけられています。このコードにより、SSLシステムは証明書を検証しません。（つまり...証明書の問題ではありません。）

明らかに1つの可能性として、esperのサーバーが正しく構成されていない可能性がありますが、私はesperのSSLポートに問題がある人を検索して他の参照を見つけず、「openssl」がそれに接続します（以下を参照）。したがって、これがJavaのデフォルトSSLサポートの制限なのか、それとも何かなのかと思います。助言がありますか？

コマンドラインから「openssl」を使用して、aperture.esper.net 6697に接続すると、次のようになります。

~ $ 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を参照）。

私がリンクしたバグレポートは、BouncyCastleのJCE実装を使用した回避策について言及しています。うまくいけば、それはあなたのために働くはずです。

更新

これはバグJDK-7044060として報告され、最近修正されました。

ただし、上限は2048ビットにしか引き上げられていないことに注意してください。2048ビットを超えるサイズの場合、 JDK-8072452-DHキーの最大プライムサイズを削除します。修正は9のようです。

「Java Cryptography Extension（JCE）Unlimited Strength Jurisdiction Policy Files」という回答は私にはうまくいきませんでしたが、BouncyCastleのJCEプロバイダーの提案はうまくいきました。

Mac OSC 10.7.5でJava 1.6.0_65-b14-462を使用して実行した手順は次のとおりです

1）これらのjarファイルをダウンロードします。

• bcprov-jdk15on-154.jar

• bcprov-ext-jdk15on-154.jar

2）これらのjarを$ 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プロバイダーを追加することも信頼できませんでした（同じエラーで失敗し、1回おきなど）。Sun SSL実装のどこかでDHEが選択されることもあれば、ECDHEが選択されることもあります。

したがって、ここに投稿されたソリューションは、TLS_DHE_暗号を完全に削除することに依存しています。注：BouncyCastleはソリューションには必要ありません。

したがって、次のようにしてサーバー証明書ファイルを作成します。

echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

TLS_DHE_暗号スイートを除く、SSL http getの解決策は後で参照されるため、後で参照するため、これを保存します。

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

    }
}

最後に、これを使用する方法を示します（opensslから保存された証明書のパスの場合はcertFilePath）。

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*..)

これは、私が見つけた1つのフォーラムスレッドでも議論されていますが、解決策については触れられていません。 http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

私は自分のケースで機能する代替ソリューションを見つけましたが、まったく満足していません。解決策は、Diffie-Hellmanアルゴリズムがまったく使用できないように設定することです。次に、サーバーが代替アルゴリズムをサポートしているとすると、通常のネゴシエーション中に選択されます。明らかに、これの欠点は、誰かがなんとかして1024ビット以下のDiffie-Hellmanのみをサポートするサーバーを見つけた場合、以前は機能していなかった場所で機能しないことを意味します。

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

不快な。

jdkでDHEを完全に無効化し、jre / lib / security / java.securityを編集して、DHEが無効化されていることを確認できます。お気に入り

jdk.tls.disabledAlgorithms=SSLv3, DHE。

プロバイダーは動的にインストールできます。

1）これらのjarファイルをダウンロードします。

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

2）jarを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にアップグレードします。このアップデートで問題が修正されました。

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>

Javaダウンロードサイトから「Java Cryptography Extension（JCE）Unlimited Strength Jurisdiction Policy Files」をダウンロードして、JRE内のファイルを置き換えてみてください。

これは私にとってはうまくいき、BouncyCastleを使用する必要すらありませんでした-標準のSun JCEはサーバーに接続できました。

PS。ポリシーファイルを変更する前にBouncyCastleを使用しようとしたときに同じエラー（ArrayIndexOutOfBoundsException：64）が発生したため、状況は非常に似ているようです。

あなたはまだこの問題にかまされている場合と、あなたは、Apache HTTPDを使用しているV> 2.4.7を、これを試してみてください。 http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

URLからコピー：

バージョン2.4.7以降、mod_sslは1024ビットを超える長さの素数を含むDHパラメータを使用します。ただし、Java 7以前では、DH素数サイズのサポートが最大1024ビットに制限されています。

Javaベースのクライアントがjava.lang.RuntimeExceptionなどの例外で異常終了した場合：DHキーペアおよびjava.security.InvalidAlgorithmParameterExceptionを生成できませんでした：素数サイズは64の倍数である必要があり、512から1024（両端を含む）までの範囲である必要があります。 httpdがtlsv1アラートの内部エラー（SSLアラート番号80）をログに記録します（LogLevel情報以上）。SSLCipherSuiteを使用して（おそらくSSLHonorCipherOrderと組み合わせて）mod_sslの暗号リストを再配置するか、1024ビットプライムでカスタムDHパラメーターを使用できます。常に組み込みのDHパラメータよりも優先されます。

カスタムDHパラメータを生成するには、

openssl dhparam 1024

コマンド。または、RFC 2409のセクション6.2にある次の標準1024ビットDHパラメータを使用できます。

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

SSLCertificateFileディレクティブを使用して設定した最初の証明書ファイルの最後に、「BEGIN DH PARAMETERS」行と「END DH PARAMETERS」行を含むカスタムパラメータを追加します。

クライアント側でJava 1.6を使用していますが、問題は解決しました。私は暗号スイートなどを下げませんでしたが、証明書ファイルにカスタム生成されたDHパラメータを追加しました。

Yandex Mapsサーバー、JDK 1.6、Apache HttpClient 4.2.1でも同じ問題があります。エラーは

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

デバッグを有効-Djavax.net.debug=all にすると、ログにメッセージがありました

Could not generate DH keypair

BouncyCastleライブラリbcprov-jdk16-1.46.jarを追加し、マップサービスクラスにプロバイダーを登録することで、この問題を修正しました

public class MapService {

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

    public GeocodeResult geocode() {

    }

}

の最初の使用時にプロバイダーが登録されMapServiceます。

JDK 6を実行しているCentOSサーバーでSSLエラーが発生しました。

私の計画は、JDK 6と共存させるために、より高いJDKバージョン（JDK 7）をインストールすることでしたが、新しい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にアップグレードすることで問題を解決しました。

私はJDK 1.6.45でcoldfusion 8を使用していて、画像の代わりに赤い十字だけを表示すること、およびcfhttpがsslでローカルWebサーバーに接続できないことに問題がありました。

coldfusion 8で再現するための私のテストスクリプトは

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

これにより、「I / O例外：ピアが認証されていません」という非常に一般的なエラーが発生しました。次に、ルート証明書と中間証明書を含むサーバーの証明書をjavaキーストアとcoldfusionキーストアに追加しようとしましたが、何も役に立ちませんでした。それから私は問題をデバッグしました

java SSLPoke www.onlineumfragen.com 443

そして得た

javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair

そして

Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive)
    at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
    at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
    ... 10 more

次に、Webサーバー（私の場合はApache）にはsslの非常に最新の暗号があり、かなり制限があり（qualysスコアa +）、1024ビットを超える強力なdiffie hellmannキーを使用するという考えがありました。明らかに、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がある場所にインストールします。coldfusion8の元のインストールでは、C：\ JRun4 \の下にありますjre \ lib \ extですが、coldfusionディレクトリの外にある新しいjdk（1.6.45）を使用しています。bcprov-ext-jdk15on-156.jarを\ extディレクトリに配置することは非常に重要です（これにより、約2時間と髪の毛がかかります;-)次に、ファイルC：\ jdk6_45 \ jre \ lib \ security \を編集しましたjava.security（editor.exeではなくワードパッドを使用！）し、新しいプロバイダー用に1行で入力します。その後、リストは次のようになりました

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

正確な暗号を指定すると、長い目で見れば破損する可能性があることに注意してください。

同じ正確な例外エラーが返されましたが、何時間もインターネットをサーフィンした後で簡単に修正できました。

oracle.comにあるjdkの最新バージョンをダウンロードしてインストールし、Jbossアプリケーションサーバーにインストールされた新しいjdkのディレクトリを指定しました。

Jbossを再起動し、再処理し、問題を修正しました!!!

Bamboo 5.7 + Gradleプロジェクト+ Apacheでこのエラーが発生しました。Gradleは、SSLを介してサーバーの1つからいくつかの依存関係を取得しようとしました。

解決：

1. DHパラメータを生成：

OpenSSLの場合：

openssl dhparam 1024

出力例：

-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----

2. 出力を証明書ファイルに追加（Apache- SSLCertificateFileparamの場合）

3. Apacheを再起動します

4. Bambooを再起動します

5. もう一度プロジェクトをビルドしてみてください

IBM JDKを使用してjava SVNクライアントでsvn.apache.orgにアクセスするときに同様のエラーが発生していました。現在、svn.apache.orgはクライアントの暗号設定を使用しています。

パケットキャプチャ/ javax.net.debug = ALLで1回だけ実行した後、単一のDHE暗号のみをブラックリストに登録することができました。

.../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を使用しています