javax.net.ssl.SSLException in jMeter
Asked Answered
G

1

1

I am testing some functionality on server. It was working fine till yesterday. Today they have enabled ssl to server (i.e, From http to https). Now when I am running my test plans I'm getting the following error. How can I resolve this issue.

Though I am changing the protocol value to https in my request I'm getting the following error,

javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:436)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
    at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
    at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
    at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
    at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
    at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(Unknown Source)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(Unknown Source)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    ... 17 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(Unknown Source)
    ... 24 more

What was the reason for it? Do I need to add anything in my request?

Gestate answered 26/11, 2014 at 15:44 Comment(0)
S
1

Dupe of Java: Why does SSL handshake give 'Could not generate DH keypair' exception? and Java 7 and Could not generate DH keypair except update Java8 has lifted the DH limit to 2048.

This occurs when your client Java (JSSE) and the server negotiate a ciphersuite using ephemeral Diffie-Hellman (DHE) and the server uses D-H size larger than 1024 bits and your client Java doesn't support it. This depends on the combination of your client Java version and the server implementation and (usually) configuration, which you don't specify.

If your client (here jmeter) runs on Java6 or Java7, it cannot handle DH size over 1024, which is now considered necessary for security and required by authorities like NIST for the US government. Solutions in descending desirability are:

  • run client on Java8 (assuming server only wants DHE 2048 bits as is now standard/conventional)

  • if the server also supports ECDHE, and either prefers it over DHE or honors client preference, use edit any Java8 or /edit recent Java7 (which supports ECDHE and prefers it after about 7u09) or use Java6 with an ECC provider added (which supports and prefers ECDHE) (but Java6 is no longer supported and thus a Bad Idea in general, as well as possibly not supporting a recently-compiled client).

  • if the server also supports plain-RSA (no ephemeral) change your client to only negotiate that. For standard Java HttpsURLConnection this can be done with system property https.cipherSuites; I don't know if Apache httpclient does the same or equivalent. This does not provide Perfect Forward Secrecy for your client, which is less than ideal but more than nothing.

  • change the server to use DHE of 1024 bits (a little less secure for other clients) or only plain-RSA (even less secure for others)

Solfa answered 26/11, 2014 at 17:9 Comment(1)
@Precious Java8 can help two ways. First if the server supports ECDHE Java8 will get it assuming server agrees and work; Java6 didn't try ECDHE. Second if the server doesn't support ECDHE but is using DHE 2048 bits as is now common, Java8 will work. Only if the server doesn't do ECDHE but does do DHE over 2048 bits will Java8 fail. Aside from trying it, you could determine the DHE size with a line capture (I prefer www.Wireshark.org but there are others) or openssl commandline s_client with -msg.Solfa

© 2022 - 2024 — McMap. All rights reserved.