問題描述
當我與一些 IRC 服務器(但不是其他服務器 - 可能是由于服務器的首選加密方法)建立 SSL 連接時，我收到以下異常:
When I make an SSL connection with some IRC servers (but not others - presumably due to the server's preferred encryption method) I get the following exception:
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 是未證明該問題的服務器示例.[毫不奇怪，每個網絡上的所有服務器都共享相同的各自行為.]
An example of a server that demonstrates this problem is aperture.esper.net:6697 (this is an IRC server). An example of a server that does not demonstrate the problem is kornbluth.freenode.net:6697. [Not surprisingly, all servers on each network share the same respective behaviour.]
我的代碼(如前所述，在連接到某些 SSL 服務器時確實有效)是:
My code (which as noted does work when connecting to some SSL servers) is:
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 引發(fā)了異常.是的，trustAllCerts"有一些魔力；該代碼強制 SSL 系統(tǒng)不驗證證書.(所以...不是證書問題.)
It's that last startHandshake that throws the exception. And yes there is some magic going on with the 'trustAllCerts'; that code forces the SSL system not to validate certs. (So... not a cert problem.)
顯然，一種可能性是 esper 的服務器配置錯誤，但我搜索并沒有找到任何其他關于 esper 的 SSL 端口有問題的人的引用，并且openssl"連接到它(見下文).所以我想知道這是否是 Java 默認 SSL 支持的限制，或者其他什么.有什么建議嗎?
Obviously one possibility is that esper's server is misconfigured, but I searched and didn't find any other references to people having problems with esper's SSL ports, and 'openssl' connects to it (see below). So I'm wondering if this is a limitation of Java default SSL support, or something. Any suggestions?
當我從命令行使用openssl"連接到 Aperture.esper.net 6697 時會發(fā)生以下情況:
Here's what happens when I connect to aperture.esper.net 6697 using 'openssl' from commandline:
~ $ 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 應用程序所能說的要多.
As noted, after all that, it does connect successfully which is more than you can say for my Java app.
如果相關的話，我使用的是 OS X 10.6.8，Java 版本 1.6.0_26.
Should it be relevant, I'm using OS X 10.6.8, Java version 1.6.0_26.
推薦答案
問題是素數大小.Java 接受的最大可接受大小是 1024 位.這是一個已知問題(請參閱 JDK-6521495).
The problem is the prime size. The maximum-acceptable size that Java accepts is 1024 bits. This is a known issue (see JDK-6521495).
我鏈接到的錯誤報告提到了 解決方法 使用 BouncyCastle 的 JCE 實現(xiàn).希望這對你有用.
The bug report that I linked to mentions a workaround using BouncyCastle's JCE implementation. Hopefully that should work for you.
更新
這被報告為錯誤 JDK-7044060 并在最近修復.
This was reported as bug JDK-7044060 and fixed recently.
但請注意，該限制僅提高到 2048 位.對于大小 > 2048 位，有 JDK-8072452 - 刪除 DH 密鑰的最大素數;修復似乎適用于 9.
Note, however, that the limit was only raised to 2048 bit. For sizes > 2048 bit, there is JDK-8072452 - Remove the maximum prime size of DH Keys; the fix appears to be for 9.
這篇關于為什么 SSL 握手會給出“無法生成 DH 密鑰對"異常?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！