[英]Why does SSL handshake give 'Could not generate DH keypair' exception?
当我与一些 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 系统不验证证书。 (所以......不是证书问题。)
显然,一种可能性是 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密码术扩展(JCE)无限强度管辖权策略文件”答案对我不起作用,但BouncyCastle的JCE提供者建议有效。
这是我在Mac OSC 10.7.5上使用Java 1.6.0_65-b14-462采取的步骤
1)下载以下罐子:
2)将这些罐子移到$ JAVA_HOME / lib / ext
3)如下编辑$ JAVA_HOME / lib / security / java.security:security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider
使用JRE重新启动应用程序并尝试一下
这是我的解决方案(java 1.6),也很感兴趣为什么我必须这样做:
我从javax.security.debug = ssl注意到,有时使用的密码套件是TLS_DHE _...,有时是TLS_ECDHE_....。如果我添加BouncyCastle,则会发生后者。 如果选择了TLS_ECDHE_,则大部分时间都可以使用,但并非总是如此,因此即使添加BouncyCastle提供程序也是不可靠的(每两次左右都失败,并出现相同的错误)。 我猜想在Sun 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 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问题
我找到了一种适用于我的情况的替代解决方案,尽管我对此并不满意。 解决方案是对其进行设置,以使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()]));
讨厌。
您可以动态安装提供程序:
1)下载以下罐子:
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());
您可以在jdk中完全禁用DHE,编辑jre / lib / security / java.security并确保禁用了DHE,例如。 喜欢
jdk.tls.disabledAlgorithms=SSLv3, DHE
。
这是一个很老的文章,但是如果使用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
从网址复制 :
从版本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信息或更高级别),您可以通过SSLCipherSuite重新安排mod_ssl的密码列表(可能与SSLHonorCipherOrder结合使用),或者可以将自定义DH参数与1024位素数结合使用,它将始终优先于任何内置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-----
将自定义参数(包括“ BEGIN DH PARAMETERS”和“ END DH PARAMETERS”行)添加到使用SSLCertificateFile伪指令配置的第一个证书文件的末尾。
我在客户端使用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>
尝试从Java下载站点下载“ Java密码学扩展(JCE)无限强度管辖权策略文件”,然后替换JRE中的文件。
这对我有用,我什至不需要使用BouncyCastle-标准的Sun JCE能够连接到服务器。
PS。 我在更改策略文件之前尝试使用BouncyCastle时遇到了相同的错误(ArrayIndexOutOfBoundsException:64),因此看来我们的情况非常相似。
我对Yandex Maps服务器,JDK 1.6和Apache HttpClient 4.2.1有相同的问题。 错误是
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
通过-Djavax.net.debug=all
debug启用调试,在日志中-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版本(JDK 7)与JDK 6共存,但事实证明,仅使用rpm -i
安装更新的JDK是不够的。
如下所示,只有通过rpm -U
升级选项,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"
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
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...
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安装替代安全提供程序,因此我决定使用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,但是我使用位于Coldfusion目录外部的较新的jdk(1.6.45)。 将bcprov-ext-jdk15on-156.jar放在\\ ext目录中非常重要(这花了我大约两个小时的时间;-),然后我编辑了文件C:\\ jdk6_45 \\ jre \\ lib \\ security \\ java.security(使用写字板而不使用editor.exe!),并为新提供程序输入一行。 之后列表看起来像
#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
(请参阅位置1中的新位置)
然后完全重新启动Coldfusion服务。 你可以
java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
并享受这种感觉...当然
什么夜晚,什么日子。 希望这会对部分人(部分或全部)有所帮助。 如果您有任何疑问,请发邮件至info ...(以上域)。
如果服务器支持不包含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从我们的一台服务器中获取某些依赖项。
解:
使用OpenSSL:
openssl dhparam 1024
示例输出:
-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----
将输出追加到证书文件(对于Apache- SSLCertificateFile
参数)
重新启动Apache
重新启动Bamboo
尝试再次构建项目
我以前在使用IBM JDK使用Java SVN客户端访问svn.apache.org时遇到类似的错误。 当前,svn.apache.org为用户提供客户端密码首选项。
在使用数据包捕获功能运行一次/ javax.net.debug = ALL之后,我仅将一个DHE密码列入了黑名单,并且一切对我来说都有效(改为协商ECDHE)。
.../java/jre/lib/security/java.security:
jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA
一个不容易更改客户端的快速解决方案。
最近,我遇到了同样的问题,并将jdk版本从1.6.0_45升级到jdk1.7.0_191 ,这解决了该问题。
Window -> 首选项 -> Java -> 已安装的 JRE -> 选择 jre 并编辑。 并在默认 VM Arguments 中输入
-Dcom.sun.net.ssl.enableECC=false
点击完成
对我来说,以下命令行解决了该问题:
java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true -Djavax.net.debug=ssl:handshake XXXXX.jar
我正在使用JDK 1.7.0_79
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.