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/[email protected]
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/[email protected]
verify return:1
---
Certificate chain
0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
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/[email protected]
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
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実装を使用している 回避策 について言及しています。うまくいけば、それはあなたのために働くはずです。
UPDATE
これはバグとして報告されています JDK-704406 そして最近修正されました。
ただし、制限は2048ビットまでしか上げられていないことに注意してください。 2048ビットを超えるサイズの場合、 JDK-8072452 - DHキーの最大素数サイズを削除 ;この修正は9用です。
「Java Cryptography Extension（JCE）無制限強度管轄ポリシーファイル」という答えは私にはうまくいきませんでしたが、BouncyCastleのJCEプロバイダの提案はうまくいきました。
Mac OSC 10.7.5でJava 1.6.0_65-b14-462を使用して行った手順は次のとおりです。
1）これらの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プロバイダさえ追加することは信頼できませんでした（同じエラーで失敗するか、それ以外の場合は毎回）。私は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-問題
私は私の場合にはうまくいく代替解決策を見つけました、私はそれに全く満足していませんが。解決策は、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.jarbcprov-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にアップグレードしてください。問題はそのアップデートで修正されました。
Javaダウンロードサイト から「Java Cryptography Extension（JCE）無制限強度管轄ポリシーファイル」をダウンロードして、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 keypairおよびJava.security.InvalidAlgorithmParameterExceptionを生成できませんでした。プライムサイズは64の倍数でなければならず、512から1024までの範囲にすることができます。 httpdはtlsv1アラートの内部エラー（SSLアラート番号80）（LogLevel情報以上）をログに記録するか、SSLCipherSuiteを使用して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パラメータを追加した。
誤った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>
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 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
私はそれからウェブサーバー（私の場合はApache）はsslのための非常に現代的な暗号を持っていて、かなり制限があり（qualysスコアa +）そして1024ビット以上の強いdiffie hellmannキーを使うという考えを持ちました。明らかに、coldfusionとJava jdk 1.6.45ではこれを管理できません。次のステップでは、Java用の代替セキュリティー・プロバイダーをインストールすることを検討しました。そこで私は弾力のある城を選びました。また参照してください http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-Eclipse-for-Java-jse- projects /
それから私はダウンロードした
bcprov-ext-jdk15on-156.jar
http://www.bouncycastle.org/latest_releases.html からインストールしてC：\ jdk6_45\jre\lib\extにインストールするか、あなたのjdkがあるところならどこでも、coldfusion 8の最初のインストールではそうなるでしょう。 C：\ JRun4\jre\lib\extにありますが、私は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（上記のドメイン）にメールしてください。
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にアップグレードすることで問題を解決しました。
私たちは、インターネットを何時間もサーフィンした後でそれが簡単であることを修正するために、返されたものと同じ正確な例外エラーを得ました。
Oracle.comで入手可能な最新バージョンのjdkをダウンロードしてインストールし、Jbossアプリケーションサーバーをインストールされた新しいjdkのディレクトリを指すようにしました。
Jbossを再起動し、再処理し、問題を解決しました!!!
私は以前、IBM SVKクライアントでIBM JDKを使ってsvn.Apache.orgにアクセスすると、同様のエラーが発生しました。現在、svn.Apache.orgのユーザーはクライアントの暗号化設定を使用しています。
Packet capture/javax.net.debug = ALLを使用して1回だけ実行した後、1つのDHE暗号だけをブラックリストに登録することができました（代わりにECDHEがネゴシエートされます）。
.../Java/jre/lib/security/Java.security:
jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA
クライアントを変更するのが容易ではない場合のすばやい修正。
最近私は同じ問題を抱えていて、1.6.0_45からjdk1.7.0_191にjdkのバージョンをアップグレードした後問題を解決しました。
私はBamboo 5.7 + Gradleプロジェクト+ Apacheでこのエラーが出ました。 Gradleは私達のサーバーの1つからSSL経由で依存関係を取得しようとしました。
Solution：
- DHパラメータを生成します。
openSSLの場合：
openssl dhparam 1024
出力例：
-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----
証明書ファイルに出力を追加する（Apacheの場合 -
SSLCertificateFileparam）Apacheを再起動します
竹を再起動
もう一度プロジェクトを構築してみてください
サーバーがDHを含まない暗号をサポートしている場合は、クライアントにその暗号を選択させ、DHエラーを回避させることができます。といった：
String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);
正確な暗号を指定すると、長期的には破損する可能性があります。