Bug ID: JDK-8180323 6u141/6u151 Could not generate DH keypair

Type: Bug
Component: security-libs
Sub-Component: javax.crypto
Affected Version: 6u151

Priority: P3
Status: Closed
Resolution: Not an Issue

Submitted: 2017-05-12
Updated: 2017-08-25
Resolved: 2017-08-25

After updating JRockit from  R128.3.11 JDK1.6.0_121 to R28.3.15
JDK1.6.0_141, failure to establish an SSL handshake with an HTTPS endpoint
that provides a public key 4096 bits long with the following error. (Same
error occurs when testing JRockit R28.3.15 JDK1.6.0_151.)

ERROR
-----------------------
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must
be multiple of 64, and can only range from 512 to 1024 (inclusive), or 2048

" If you check the difference between the 6u121 and 6u141 logs, you'll see that the client has stopped offering the ECDHE based ciphersuites. It now opts to use the DH keys but they're not compatible with the DH constraints in JDK 6. " More updates from submitter. seems that installing and configuring BoucyCastle solved their issue. I suspect that they had a bad configuration after upgrading their JDK version. EC was offered in older JDK and that's not offered out of the box by default on JDK 6/Linux. As a result 6u141 was defaulting to DH based ciphersuites for this server connection. Server was request 4096 bit key which is too large for current JDK 6 offering. "The use of BouncyCastle will provide the app with EC crypto capabilities. They are not available by default in JDK 6. I can only assume that Cu had a similar arrangement in their config files (or elsewhere) for 6u121. The 6u121 logs show that EC was available so they MUST have been modifying the default config. "

25-08-2017

[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)', handling exception: java.lang.RuntimeException: Could not generate DH keypair %% Invalidated: [Session-91,TLS_DHE_RSA_WITH_AES_128_CBC_SHA] From the new log file that was supplied, we see 132 TLS connections. Of those, 131 use non DH for key exchange (TLS_RSA_WITH_AES_128_CBC_SHA). Only one used DH TLS_DHE_RSA_WITH_AES_128_CBC_SHA and this is the handshake that's causing the above error message. Cu need to identify the application making this communication. It is possible for it to use non DH based ciphersuite ? I miscalculated the size of the server DH key. It's 512*8 bits in length, 4096 bits. Currently, for JDK 6u, the DH key size must be a multiple of 64, and can only range from 512 to 2048 (inclusive). Has the server environment been upgraded ? We normally print such an explicit warning message in exception, but some application code appears to be swallowing that message. Relief can be provided by 2 options : A) reduce the DH keysize on server to 2048 bits (max) B) Use an RSA based ciphersuite for key exchange protocol. Can you suggest these options to submitter ? In the working logs, I don't see any use/agreement on the problem ciphersuite : $grep "Cipher Suite\:" * | grep TLS_DHE_RSA_WITH_AES_128_CBC_SHA

26-05-2017

I think this issue is related to JDK-8072452 - I think more than just the JDK must have changed in this scenario. Has the other end point in this SSL config been upgraded ? The DH key on the other end point appears to be larger than the current max limit of 2048.

15-05-2017