Bug 56357

Summary: Certificates does not conform to algorithm constraints: Adding a note to indicate how to remove of the Java installation these new security constraints
Product: JMeter Reporter: Mayur Dhande <memayurdhande>
Component: HTTPAssignee: JMeter issues mailing list <issues>
Status: RESOLVED FIXED    
Severity: normal CC: maran88, p.mouawad
Priority: P2    
Version: 2.11   
Target Milestone: ---   
Hardware: Sun   
OS: All   

Description Mayur Dhande 2014-04-07 12:15:33 UTC
Hi,
I am getting the SSL error in Jmeter continuously as below:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
	at sun.security.ssl.Alerts.getSSLException(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
	at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
	at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
	at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
	at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
	at sun.security.ssl.Handshaker.processLoop(Unknown Source)
	at sun.security.ssl.Handshaker.process_record(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
	at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:485)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1060)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1049)
	at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:442)
	at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:271)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(Unknown Source)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(Unknown Source)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source)
	... 18 more


So to trach the error I enbled the Log Viewer in Jmeter and from logs found that the below detail:


2014/04/07 17:06:39 INFO  - jmeter.engine.StandardJMeterEngine: Listeners will be started after enabling running version 
2014/04/07 17:06:39 INFO  - jmeter.engine.StandardJMeterEngine: To revert to the earlier behaviour, define jmeterengine.startlistenerslater=false 
2014/04/07 17:06:39 INFO  - jmeter.engine.StandardJMeterEngine: Running the test! 
2014/04/07 17:06:39 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(true,*local*) 
2014/04/07 17:06:40 INFO  - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group Thread Group. 
2014/04/07 17:06:40 INFO  - jmeter.engine.StandardJMeterEngine: Thread will continue on error 
2014/04/07 17:06:40 INFO  - jmeter.threads.JMeterThread: jmeterthread.startearlier=true (see jmeter.properties) 
2014/04/07 17:06:40 INFO  - jmeter.threads.JMeterThread: Running PostProcessors in forward order 
2014/04/07 17:06:40 INFO  - jmeter.engine.StandardJMeterEngine: All threads have been started 
2014/04/07 17:06:40 INFO  - jmeter.threads.JMeterThread: Thread started: Thread Group 1-1 
2014/04/07 17:06:44 INFO  - jmeter.protocol.http.sampler.HTTPJavaImpl: Maximum connection retries = 10 
2014/04/07 17:06:44 INFO  - jmeter.util.JsseSSLManager: Using default SSL protocol: TLS 
2014/04/07 17:06:44 INFO  - jmeter.util.JsseSSLManager: SSL session context: per-thread 
2014/04/07 17:06:44 INFO  - jmeter.util.SSLManager: JmeterKeyStore Location:  type JKS 
2014/04/07 17:06:44 INFO  - jmeter.util.SSLManager: KeyStore created OK 
2014/04/07 17:06:44 WARN  - jmeter.util.SSLManager: Keystore file not found, loading empty keystore 
2014/04/07 17:06:45 INFO  - jmeter.threads.JMeterThread: Thread finished: Thread Group 1-1 
2014/04/07 17:06:45 INFO  - jmeter.engine.StandardJMeterEngine: Ending thread Thread Group 1-1 
2014/04/07 17:06:45 INFO  - jmeter.engine.StandardJMeterEngine: Notifying test listeners of end of test 
2014/04/07 17:06:45 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(false,*local*) 
2014/04/07 17:06:45 INFO  - jmeter.engine.StandardJMeterEngine: Test has ended on host null 


Can someone please help me to get rid out from this SSL issue??
Comment 1 Philippe Mouawad 2014-04-07 20:35:32 UTC
Hello,
What java version are you using ?
Can you attach details of your certificate as shown by Firefox ? I want to see algorithms used for hashing ?


Look at this:
http://stackoverflow.com/questions/14149545/java-security-cert-certificateexception-certificates-does-not-conform-to-algori

And make tests by setting in user.properties:
# Default HTTPS protocol level:
#https.default.protocol=TLS
# This may need to be changed here (or in user.properties) to:
#https.default.protocol=SSLv3

# List of protocols to enable. You may have to select only a subset if you find issues with target server.
# This is needed when server does not support Socket version negotiation, this can lead to:
# javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
# java.net.SocketException: Connection reset
# see https://issues.apache.org/bugzilla/show_bug.cgi?id=54759
#https.socket.protocols=SSLv2Hello SSLv3 TLSv1

Thanks
Comment 2 Mayur Dhande 2014-04-08 10:46:00 UTC
Hi,
I am using the jdk1.7.0_17.Also for this I haven't instilled any certificate ,I am just passing the username and password and try to login on our production environment.But it throws an SSL error.
Comment 3 Philippe Mouawad 2014-04-16 19:25:46 UTC
Could you hit in Firefox the URL you use in your test.
Then click on the padlock and More Information, Tab Security > View Certificate > Details > Export.
Comment 4 Mayur Dhande 2014-05-14 14:30:32 UTC
Hello,
Still I am getting the same error.
Please find the logs for this :
2014/05/14 19:52:56 INFO  - jmeter.engine.StandardJMeterEngine: Running the test! 
2014/05/14 19:52:56 INFO  - jmeter.samplers.SampleEvent: List of sample_variables: [] 
2014/05/14 19:52:56 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(true,*local*) 
2014/05/14 19:52:57 INFO  - jmeter.engine.StandardJMeterEngine: Starting ThreadGroup: 1 : Thread Group 
2014/05/14 19:52:57 INFO  - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group Thread Group. 
2014/05/14 19:52:57 INFO  - jmeter.engine.StandardJMeterEngine: Thread will continue on error 
2014/05/14 19:52:57 INFO  - jmeter.threads.ThreadGroup: Starting thread group number 1 threads 1 ramp-up 1 perThread 1000.0 delayedStart=false 
2014/05/14 19:52:57 INFO  - jmeter.threads.ThreadGroup: Started thread group number 1 
2014/05/14 19:52:57 INFO  - jmeter.engine.StandardJMeterEngine: All thread groups have been started 
2014/05/14 19:52:57 INFO  - jmeter.threads.JMeterThread: Thread started: Thread Group 1-1 
2014/05/14 19:53:03 INFO  - jmeter.threads.JMeterThread: Thread finished: Thread Group 1-1 
2014/05/14 19:53:03 INFO  - jmeter.engine.StandardJMeterEngine: Notifying test listeners of end of test 
2014/05/14 19:53:03 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(false,*local*)
Comment 5 Philippe Mouawad 2014-05-25 20:19:33 UTC
Closing as no answer received to required infos.
Comment 6 Milamber 2014-10-16 06:03:46 UTC
This bug is related to Java version.

Since Java 7 u16, the sign algo MD2 is disable.
http://www.oracle.com/technetwork/java/javase/6u17-141447.html

A simple workaround is to revert the disable.
Edit the JDK_HOME/jre/lib/security/java.security
And change 
jdk.certpath.disabledAlgorithms=MD2

(or jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
since Java 7 u40 & Java 8)

to
jdk.certpath.disabledAlgorithms=

(or jdk.certpath.disabledAlgorithms=RSA keySize < 1024
since Java 7 u40 & Java 8))


I re-open the issue to find the good way with JMeter to not use the MD2 signature algorithm.
Comment 7 Milamber 2014-10-16 06:05:35 UTC
For reference:

http://www.oracle.com/technetwork/java/javase/7u40-relnotes-2004172.html

Default x.509 Certificates Have Longer Key Length

Starting from 7u40, the use of x.509 certificates with RSA keys less than 1024 bits in length is restricted. This restriction is applied via the Java Security property, jdk.certpath.disabledAlgorithms. The default value of jdk.certpath.disabledAlgorithms is now as follows:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

In order to avoid the compatibility issue, users who use X.509 certificates with RSA keys less than 1024 bits, are recommended to update their certificates with stronger keys. As a workaround, at their own risk, users can adjust the key size to permit smaller key sizes through the security property jdk.certpath.disabledAlgorithms.
Comment 8 Sebb 2014-10-16 19:14:55 UTC
Generally JMeter tries allow testing of all sites. For example, JMeter does not do hostname checks.

It is assumed that the user knows best regarding the URLs that are used in a Test Plan.

So ideally JMeter should be able to continue to support testing of such HTTPS servers, even though they are not as secure as they should be.
Comment 9 Milamber 2014-10-16 20:05:56 UTC
I'm not sure of the reason of your comment, it's a Java issue. The Java (security) team have change the minimal signature algorithm and key size with latest Java7/8 version. JMeter stops "works" because the signalg and keysize are incorrect (on JMeter proxy tool with websites which don't expose SSLv3/MD2/1024bits SSL cipher/algo/key size).

The objective is to have a JMeter tool which works with Java lastest of version 7 and 8 (and 6). On my mind, it's normal (and secure) to update my Java version to avoid security issue, and have a JMeter (default install) works.
Comment 10 Philippe Mouawad 2014-10-16 20:09:46 UTC
Now it's much clearer for me. Thanks milamber
Comment 11 Sebb 2014-10-16 20:30:39 UTC
(In reply to Milamber from comment #9)
> I'm not sure of the reason of your comment, it's a Java issue. The Java
> (security) team have change the minimal signature algorithm and key size
> with latest Java7/8 version. 

Agreed, it is a Java change.

> JMeter stops "works" because the signalg and
> keysize are incorrect (on JMeter proxy tool with websites which don't expose
> SSLv3/MD2/1024bits SSL cipher/algo/key size).

The original description is not about the Proxy, it is about the HTTPS Sampler.

Also, it looks as though the problem is that the certificate that is returned by the server is no longer acceptable.

Does the server return a different certificate if JMeter connects with a different cipher?

> The objective is to have a JMeter tool which works with Java lastest of
> version 7 and 8 (and 6). On my mind, it's normal (and secure) to update my
> Java version to avoid security issue, and have a JMeter (default install)
> works.

There are two issues here.

Updating the default SSL cipher if necessary.

Updating JMeter - if possible - so it still works against sites that return outdated certificates. If it's not possible to change the JVM behaviour at run-time, then ensure that we document how to fix the problem. Possibly detect the specific failure message and log a message pointing to the docn.
Comment 12 Milamber 2014-10-19 16:31:16 UTC

URL: http://svn.apache.org/r1632953
Log:
Certificates does not conform to algorithm constraints: Adding a note to indicate how to remove of the Java installation these new security constraints
Bugzilla Id: 56357

Modified:
    jmeter/trunk/xdocs/changes.xml
    jmeter/trunk/xdocs/usermanual/component_reference.xml
Comment 13 Milamber 2014-10-19 16:54:01 UTC

For reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2409
Comment 14 Felix Schumacher 2017-01-03 19:09:33 UTC
*** Bug 60546 has been marked as a duplicate of this bug. ***