获取无法生成DH密钥对异常 [英] Getting Could not generate DH keypair Exception

问题描述

vCenter(5.5)尝试从https服务器下载zip文件时出现此异常. VCenter服务器具有JRE 1.6.0.31.我知道与Java 1.6和1.7中相同问题相关的错误.此异常是由java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)引起的.

I am getting this exception when vCenter(5.5) try to download zip file from a https server. VCenter server has JRE 1.6.0.31. I am aware of bug related to same issue in Java 1.6 and 1.7. This exception is caused by java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive).

我可以从https服务器更改SSL证书.我试图通过使用OpenSSL(openssl req -new -x509 -newkey rsa:1024 -days 365 -out server.crt -extensions usr_cert )和其他选项.我看着sun.security.ssl.ClientHandshaker代码，有执行的开关盒 以下代码行并生成异常.

I can change the SSL certificate from the https server. I tried to solve this issue by generating new certificates with OpenSSL (openssl req -new -x509 -newkey rsa:1024 -days 365 -out server.crt -extensions usr_cert ) and other options as well. I looked into sun.security.ssl.ClientHandshaker code, There is switch case which executes following lines of code and generate exception.

case K_DHE_DSS:
case K_DHE_RSA:
    this.serverKeyExchange(new DH_ServerKeyExchange(input, serverKey,
    clnt_random.random_bytes, svr_random.random_bytes,messageLen));

有什么方法可以生成避免此代码执行的SSL证书(可能是没有DH密钥对的SSL证书)?

is there any way to generate SSL certificate which will avoid this code execution (may be, SSL certificate without DH keypair) ?

提前谢谢！

推荐答案

密钥交换是DHE_RSA，这意味着Diffie Hellman Ephemeral 已通过RSA认证. DHE密钥，甚至DHE参数，都不在证书中，这是长期的(FSVO长)，不是临时的.证书中的密钥是RSA，并且Java在处理安全大小的RSA时没有问题，当今的安全大小已超过1024，传统上为2048.

The keyexchange is DHE_RSA which means Diffie Hellman Ephemeral authenticated by RSA. The DHE key, and even the DHE parameters, are not in the certificate, which is longterm (FSVO long) not ephemeral. The key in the certificate is RSA, and Java has no problem dealing with RSA at secure sizes, which today is more than 1024 and conventionally 2048.

1. 直接的解决方法是使用与Java旧版本兼容的弱 DH(E)参数.可能有十几个或更多使用OpenSSL的SSL/TLS服务器程序，或者使用PEM格式的证书和(RSA)私钥格式文件. (很多软件可以使用或可以处理 cert 的PEM，但是大多数OpenSSL可以对私钥进行PEM.)许多这些服务器程序都允许配置DH(E)参数，但是我所见过的一切都有所不同，您也无法识别您的身份.

1. The direct fix is to use old-Java-compatible weak DH(E) parameters. There are probably a dozen or more SSL/TLS server programs that use OpenSSL, or otherwise use PEM format files for the cert and (RSA) privatekey. (Lots of software uses or can handle PEM for cert, but mostly OpenSSL does so for privatekey.) Many of these server programs allow configuring the DH(E) parameters, but all that I've seen do so differently, and you don't identify yours.

一种解决方法是避免DHE_anything，并使用 plain-RSA keyexchange.包括OpenSSL在内的所有SSL/TLS实现都可以实现这一点.但是，大多数应用程序和/或中间件不再喜欢它，有些甚至不允许它，因为它不提供

A workaround is to avoid DHE_anything and use plain-RSA keyexchange. All SSL/TLS implementations including OpenSSL implement this. However, most applications and/or middlewares no longer prefer it and some don't even allow it, because it doesn't provide Forward Secrecy. How you control the ciphersuites, and thus keyexchange, again depends on the unidentified server program.

一个更好的解决方法是，如果可以的话，启用 ECDHE (特别是ECDHE_RSA，因为您的证书/密钥是RSA).

A better workaround is to enable ECDHE (and specifically ECDHE_RSA, since your cert/key is RSA) if you can.

3A. Java6 JSSE实现了ECDHE协议，但是只有在JRE中有用于ECC原语的JCE提供者"时才启用它们-并且所交付的Oracle/Sun JRE6(以及TTBOMK和OpenJDK也没有)没有ECC提供程序.要将 ECC提供者添加到JRE6

3A. Java6 JSSE implements ECDHE protocols, but enables them only if there is a JCE "provider" for ECC primitives in your JRE -- and Oracle/Sun JRE6 as delivered (and TTBOMK the OpenJDK one also) does not have an ECC provider. To add ECC provider to JRE6

• 从 http://www.bouncycastle.org/latest_releases.html 并将其放入您的JRE/lib/ext

编辑JRE/lib/security/java.security，将类似security.provider.N=org.bouncycastle.jce.provider.BouncyCastleProvider的行添加到提供商列表中，其中N是下一个可用数字.

edit JRE/lib/security/java.security to add to the list of providers a line like security.provider.N=org.bouncycastle.jce.provider.BouncyCastleProvider where N is the next available number.

JRE7确实包含ECC提供程序，并且如果可以选择的话，还支持现成的ECDHE.

JRE7 does include ECC provider, and supports ECDHE out-of-the-box, if that is an option.

3B.如果您的服务器使用OpenSSL 1.0.0或更高版本(某些较旧的RedHat版本除外)，它将实现ECDHE，但只有在启用()(1)密码套件的情况下，才能使用它，默认情况下为true，但是可以由服务器程序或其配置禁用，和(2)服务器程序设置tmp_ecdh参数(或在1.0.2中启用自动设置).这两个都依赖于身份不明的服务器程序，如果服务器程序不使用OpenSSL，答案可能会大不相同.

3B. If your server uses OpenSSL 1.0.0 or higher (except for certain older RedHat builds) it implements ECDHE, but it can be used only if (1) the ciphersuites are enabled, which is true by default but could be disabled by the server program or its configuration, and (2) the server program sets tmp_ecdh parameters (or in 1.0.2 enables auto-setting). Both of these depend on the unidentified server program, and if the server program doesn't use OpenSSL the answer may be very different.

如果您标识服务器程序及其配置中与SSL/TLS相关的部分，则我(或其他人)可能会更具体.

If you identify your server program and the SSL/TLS-related parts of its configuration, I (or perhaps someone else) can be more specific.

EDIT 服务器是 nginx :

(1)nginx应该能够使用Java(6,7)可以处理的DHE参数，请参见 http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_dhparam 并使用

(1) nginx should be able to use DHE params Java(6,7) can handle, see http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_dhparam and create the file with

 openssl dhparam 1024 >mydhfile

(或者，如果您确实想要，较小的DSA-1大小= 512到1024乘以64的倍数，但是您不需要，而且我建议不要小于1024).

(or if you really want, a smaller DSA-1 size = 512 to 1024 and a multiple of 64, but you don't need and I don't recommend smaller than 1024).

(2)或者，要禁用DHE，请不添加它，但 do 在ssl_ciphers字符串中至少添加一些kRSA(或仅添加RSA).至少将您评论中的字符串更改为

(2) alernatively, to disable DHE, don't add it but do add at least some kRSA (or just RSA) in the ssl_ciphers string. Change the string in your comment at least to

 EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH:kRSA:!RC4:!aNU‌​LL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

或因为未修改的JRE6将不提供ECDHE(或TLSv1.2)并且我们没有添加任何需要删除的PSK或SRP或DSS或aNULL，并且您不信任3DES(为什么?)以及RC4和Java没有实现SEED或山茶花，您可以使用更简单的方法

or because unmodified JRE6 won't offer ECDHE (or TLSv1.2) and we haven't added any PSK or SRP or DSS or aNULL that need to be deleted, and you distrust 3DES (why?) and RC4 and Java doesn't implement SEED or Camellia, you could use much more simply just

 AES128-SHA:AES256-SHA 

(这些实际上是TLS_RSA_WITH_AES * _CBC_SHA，但出于歇斯底里的原因，OpenSSL名称省略了RSA和CBC.)

(These are actually TLS_RSA_WITH_AES*_CBC_SHA but for hysterical raisins the OpenSSL name omits the RSA, and the CBC.)

Tomcat 默认情况下使用Java(JSSE)处理HTTPS连接，但是根据打包/安装的情况，通常可以使用APR，也称为"Tomcat本机"或实际上是OpenSSL的本机".如果Tomcat/JSSE在JRE6或7上运行，它将使用JRE6,7客户端可以处理的DHE大小768.如果在JRE8上运行，则默认的大小为1024，JRE6,7客户端可以处理.我不知道Tomcat/APR使用的是什么(无法​​轻松测试)，但是它可能是1024或更小.如果要查找并运行Tomcat/APR并打开openssl 1.0.2 ，请使用openssl s_client -connect host:port -tls1 -cipher EDH+AES；否则，请使用openssl s_client -connect host:port -tls1 -cipher EDH+AES.连接时输入Q，返回；并查找约20行以获取服务器临时密钥".

Tomcat by default uses Java (JSSE) to handle HTTPS connections, but depending on the packaging/install often can use APR also called "Tomcat native" or just "native" which is actually OpenSSL. If Tomcat/JSSE is run on JRE6 or 7, it uses DHE size 768 which JRE6,7 client can handle; if run on JRE8 it defaults to size 1024 which JRE6,7 client can handle. I don't know what Tomcat/APR uses (and can't easily test) but it could well be 1024 or less. If you want to find out and have Tomcat/APR running and openssl 1.0.2 available, use openssl s_client -connect host:port -tls1 -cipher EDH+AES; when it connects enter Q, return; and look about 20 lines up for "Server Temp Key".

这篇关于获取无法生成DH密钥对异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！