Our company has upgraded from TLS 1.0 to TLS 1.2. Before this, we used to download files using org.apache.commons.net.ftp.FTPClient.
Now we cannot connect to the server using FTPSclent and we get an exception:
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication
How can I correctly connect to the server.
Full stack trace:
First of all, turn on the SSL debug as the javadoc sugests and try to connect, then check the output (it logs by default to std out, you should redirect it to a file).
The sorter answer
Give a try to the -Dhttps.protocols=TLSv1.2 JVM argument (this should be passed to every java code that you are using during your investigation and you have to use the same JRE of course too).
If does not work, check the server certificate, that should be installed to the JRE's default keystore (cacerts) or your custom keystore that you may use.
If this does not help, install the JCE extensions (JRE could not handle a cert that has at least 2048 bit key without JCE).
If all of these steps are useless, you may have the same problem than this guy.
The longer version
I hope that you are using at least Java7 (see the table of the available protocols on each platform).
The first thing is, that the TLS protocols supported by the server and supported by your application have to have an intersect.
In this table you can find the default TLS protocols of the different JRE versions, this is important because your client uses very probably the default TLS of the JRE.
So after you have checked your JRE and found the supported TLS versions, you should check the applied cyphers.
You should test your connection using nmap:
nmap.exe --script ssl-enum-ciphers -p <port> <ftp host>
with this tool, you can list the TLS version and the used cyphers. The cypher list can be compared with the list provided by this small java code. This two lists have to have at least one common point in order to be able to communicate.
You can download the server's certificate using Portecle, that certificate should be installed in the keystore of your client JRE.
If you have found that they have intersection in TLS protocols and in cyphers too, you have the right cert in your keystore, you can test that they can communicate with
SSLPoke
If this works too, then the problem should be in FTPClient.
I've been working on a Java webservice client. It works fine for everybody except for one customer who has this error:
class java.lang.IllegalArgumentException :
SSLv2Hello cannot be enabled unless at least one other supported version is also enabled
I can't reproduce the error. We're using the same server trying to test it, and it works fine for me and all of my collegues. The only thing different that we're using our certificate and the user is using his.
Tried System.setProperty("https.protocols", "SSLv3");
Then I got this:
class javax.xml.ws.WebServiceException :
Failed to access the WSDL at: https:something:someport/something/something?wsdl. It failed with:
No appropriate protocol (protocol is disabled or cipher suites are inappropriate).
The client is using:
JVM: 1.8.0_40
Operating System: Windows 7
I'm clueless how can i solve this, or what path to take to further explore the problem.
SSLv2Hello cannot come alone, it needs another protocol to be allowed (SSLv3, TLS,..)
Your code seems to work as you can test it almost anywhere with good results. It's then an environment problem on the faulty tester, by configuration or JDK version.
Check environment variables, java.security file (particularly jdk.tls.disabledAlgorithms key which can be empty for testing) , and deployment.properties file if any.
It's often a good idea to dump all environment properties during the client or server startup.
We have enabled SSL on
MQ version '7.1.0.7'
OS->'Linux 2.6.32-642.11.1.el6.x86_64'
two months back [aug-2016] and its working fine with SSL enabled and disabled mode
Java Client uses
jdk1.7.0_21
Worked cipher/suite -> SSL_RSA_WITH_RC4_128_SHA <> RC4_SHA_US
When I try to connect to a MQ v7.1.0.7 queue manager the application is throwing below error:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2397'.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:228)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:95)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
In the queue manager error log AMQERR01.LOG I see this:
AMQ9616: The CipherSpec proposed is not enabled on the server.
EXPLANATION: The SSL or TLS subsystem at the server end of a channel
been configured in such a way that it has rejected the CipherSpec
proposed by an SSL or TLS client. This rejection occurred during the
secure socket handshake (i.e. it happened before the proposed
CipherSpec was compared with the CipherSpec in the server channel
definition).
We have a MQ v6.0.2.12 queue manager where this is working fine.
Could some one provide help what went wrong for system , which was working before?
Resolved by adding below lines in qm.ini file
SSL:
AllowSSLV3=Y
AllowWeakCipherSpec=Y
Updated (2017/01/27) with additional questions:
Worked below TLSv1
TLS_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA TLSv1 TRUE
TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA TLSv1 TRUE
Failed with TLSv1.2
TLS_RSA_WITH_RC4_128_SHA256 SSL_RSA_WITH_RC4_128_SHA TLSv1.2 FALSE
I tried with these settings:
SSLContext sslContext = SSLContext.getInstance("TLSv1");
-Dcom.ibm.mq.cfg.preferTLS=true
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Error is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2397'
In the AMQERR01.LOG
There is a mismatch between the CipherSpecs on the local and remote ends
of channel 'TEST.CH'. The channel will not run until this mismatch is
resolved.The CipherSpec required in the local channel definition is
'TLS_RSA_WITH_RC4_128_SHA256'. The name of the CipherSpec negotiated during
the SSL handshake is 'RC4_SHA_US'. A code is displayed if the name of the
negotiated CipherSpec cannot be determined
Updated (2017/01/29) with additional questions:
SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
MQEnvironment.sslFipsRequired = true;
MQEnvironment.sslCipherSuite ="SSL_RSA_WITH_AES_256_CBC_SHA256";
ALTER CHANNEL(TEST.CH) CHLTYPE(SVRCONN) SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
REFRESH SECURITY TYPE(SSL)
Client Execute
/apps/java/jdk1.7.0_21/bin/java -Dcom.ibm.mq.cfg.preferTLS=true -Dcom.ibm.mq.cfg.useIBMCipherMappings=false -classpath .:/tmp/mqssl/com.ibm.mq.jmqi.jar:/tmp/mqssl/com.ibm.mq.jar:com.ibm.ws.webservices.thinclient_8.5.0.jar MQProducerSSL
Getting error as MQJE001: Completion Code '2', Reason '2400'
MQRC_UNSUPPORTED_CIPHER_SUITE (2400)
Updated (2017/01/30) with additional questions:
Still same error , but in my client java prg have enabled System.setProperty("javax.net.debug", "all"); to see all activities while execute client. Its Printing TLS_RSA_WITH_AES_256_CBC_SHA256 as Ignoring unavailable cipher suite as below
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Before call
MQJE001: Completion Code '2', Reason '2400'.
MQJE001: Completion Code '2', Reason '2400'.
Tested with IBM-JDK-71 Same Exception
SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA<><>ECDHE_ECDSA_3DES_EDE_CBC_SHA256
SSL_ECDHE_RSA_WITH_NULL_SHA<><>ECDHE_RSA_NULL_SHA256
Updated (2017/01/31) with additional questions:
com.ibm.mq.jar
Specification-Version: 7.1.0.1
Specification-Vendor: IBM Corporation
Implementation-Title: WebSphere MQ classes for Java
Implementation-Version: 7.1.0.1 - k710-001-120424
com.ibm.mq.jmqi.jar
Specification-Version: 7.1.0.1
Specification-Vendor: IBM Corporation
Implementation-Title: WebSphere MQ Interface for Java
Implementation-Version: 7.1.0.1 - k710-001-120424
Updated (2017/01/31 A) with additional questions:
Since MQ and Client Running in same machine ,got Specification-Version: 7.1.0.7 jars
Testing done with 2 scenarios by changing the classpath
Without -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
jdk1.7.0_21/bin/java -Dcom.ibm.mq.cfg.preferTLS=true -classpath .:/opt/mqm/java/lib/com.ibm.mq.jmqi.jar:/opt/mqm/java/lib/com.ibm.mq.jar MQProducerSSL
got exception MQJE001: Completion Code '2', Reason '2400'
With -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
/apps/hostlink/java/jdk1.7.0_21/jdk1.7.0_21/bin/java -Dcom.ibm.mq.cfg.preferTLS=true -Dcom.ibm.mq.cfg.useIBMCipherMappings=true -classpath .:/opt/mqm/java/lib/com.ibm.mq.jmqi.jar:/opt/mqm/java/lib/com.ibm.mq.jar MQProducerSSL
got exception MQJE001: Completion Code '2', Reason '2393'
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2393'.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:232)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:96)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:893)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:780)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:729)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:177)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:674)
at MQProducerSSL.main(MQProducerSSL.java:89)
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2393;AMQ9204: Connection to host 'localhost(2017)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2393;AMQ9771: SSL handshake failed. [1=java.lang.IllegalArgumentException[Cannot support TLS_RSA_WITH_AES_256_CBC_SHA256 with currently installed providers],3=localhost/127.0.0.1:2017 (localhost),4=SSLSocket.createSocket,5=default]],3=localhost(2017),5=RemoteTCPConnection.makeSocketSecure]
Updated (2017/01/31 B) with additional questions:
MQEnvironment.sslFipsRequired = false;
MQEnvironment.sslCipherSuite = "TLS_RSA_WITH_AES_128_CBC_SHA256";
ALTER CHANNEL(TEST.CH) CHLTYPE(SVRCONN) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256)
/apps/hostlink/java/jdk1.7.0_21/jdk1.7.0_21/bin/java -Dcom.ibm.mq.cfg.preferTLS=true -Dcom.ibm.mq.cfg.useIBMCipherMappings=false -classpath .:/opt/mqm/java/lib/com.ibm.mq.jmqi.jar:/opt/mqm/java/lib/com.ibm.mq.jar MQProducerSSL
MQJE001: Completion Code '2', Reason '2397'.
MQJE001: Completion Code '2', Reason '2397'.
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2397'.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:232)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:96)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:893)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:780)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:729)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:177)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:674)
at MQProducerSSL.main(MQProducerSSL.java:89)
Worked below TLSv1
----Spec---- TLS_RSA_WITH_DES_CBC_SHA
---Suite---- SSL_RSA_WITH_DES_CBC_SHA
TLSv1 TRUE
Not working , when given below parameters , throwing **MQJE001: Completion Code '2', Reason '2400'**
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
-Dcom.ibm.mq.cfg.preferTLS=true
doubt on TLSv1 , if TLSv1 working without above parameters , why need to provide -Dcom.ibm.mq.cfg.preferTLS=true for TLSv2?
even with IBM-JDK 7.1 also TLSv2 not working, what could be issue?
Need to try with MQ8?
Updated (2017/02/01) with additional questions:
Complete Exception in console
MQJE001: Completion Code '2', Reason '2397'.
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2397'.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:232)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:96)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:893)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:780)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:729)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:177)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:674)
at MQProducerSSL.main(MQProducerSSL.java:89)
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9204: Connection to host 'localhost(2017)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2397;AMQ9771: SSL handshake failed. [1=javax.net.ssl.SSLHandshakeException[Error signing certificate verify],3=localhost/127.0.0.1:2017 (localhost),4=SSLSocket.startHandshake,5=default]],3=localhost(2017),5=RemoteTCPConnection.protocolConnect]
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:2098)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1347)
at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:924)
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:221)
... 10 more
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9771: SSL handshake failed. [1=javax.net.ssl.SSLHandshakeException[Error signing certificate verify],3=localhost/127.0.0.1:2017 (localhost),4=SSLSocket.startHandshake,5=default]
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:1310)
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.connect(RemoteConnection.java:714)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSessionFromNewConnection(RemoteConnectionSpecification.java:356)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSession(RemoteConnectionSpecification.java:265)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionPool.getSession(RemoteConnectionPool.java:144)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1709)
... 13 more
Caused by: javax.net.ssl.SSLHandshakeException: Error signing certificate verify
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:987)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:285)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection$6.run(RemoteTCPConnection.java:1280)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection$6.run(RemoteTCPConnection.java:1273)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:1271)
... 18 more
Caused by: java.security.NoSuchAlgorithmException: SHA224withRSA Signature not available
at java.security.Signature.getInstance(Signature.java:224)
at sun.security.ssl.JsseJce.getSignature(JsseJce.java:241)
at sun.security.ssl.HandshakeMessage$CertificateVerify.<init>(HandshakeMessage.java:1552)
at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:982)
... 29 more
from AMQERR01.LOG
----- amqrmrsa.c : 930 --------------------------------------------------------
01/31/2017 08:45:00 PM - Process(14444.328) User(mqm) Program(amqrmppa)
Host(testvm) Installation(Installation1)
VRMF(7.1.0.7) QMgr(TLSTEST.QM)
AMQ9665: SSL connection closed by remote end of channel '????'.
EXPLANATION:
The SSL or TLS connection was closed by the remote host 'localhost (127.0.0.1)'
during the secure socket handshake. The channel is '????'; in some cases its
name cannot be determined and so is shown as '????'. The channel did not start.
ACTION:
Check the remote end of the channel for SSL and TLS errors. Fix them and
restart the channel.
----- amqccisa.c : 6478 -------------------------------------------------------
01/31/2017 08:45:00 PM - Process(14444.328) User(mqm) Program(amqrmppa)
Host(testvm) Installation(Installation1)
VRMF(7.1.0.7) QMgr(TLSTEST.QM)
AMQ9492: The TCP/IP responder program encountered an error.
EXPLANATION:
The responder program was started but detected an error.
The host name was 'localhost (127.0.0.1)'; in some cases the host name cannot
be determined and so is shown as '????'.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 930 --------------------------------------------------------
removed old jars from classpath , but still same exception
Console Output have below lines printed for Algorithm
matching alias: ibmwebspheremqtlstest.qm
*** Certificate chain
chain [0] = [
[
Version: V3
Signature Algorithm: SHA1withRSA,
In client , passing key.jks file , which is created at MQ level with 'runmqckm'
whether need to specify different Algorithm on creation for TLSv2 ?
TLSV2 WORKED WITH JDK8 and ibm/java-x86_64-71
SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
Oracle JDK8
MQEnvironment.sslFipsRequired = false;
MQEnvironment.sslCipherSuite = "TLS_RSA_WITH_AES_128_CBC_SHA256";
ALTER CHANNEL(TEST.CH) CHLTYPE(SVRCONN) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256)
IBM-JDK 7.1
MQEnvironment.sslFipsRequired = false;
MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_NULL_SHA256";
ALTER CHANNEL(TEST.CH) CHLTYPE(SVRCONN) SSLCIPH(TLS_RSA_WITH_NULL_SHA256)
But question on how to work any TLSv2 cipher with lesser version of Oracle java than 8?
To resolve/work-around the issue:will try one by one
1) use the IBM JVM
2) test with Oracle Java v8
3) Try MQ v8
4) other option to set SSLCAUTH=OPTIONAL and not require client side certificate.
Trying with JDK8 and MQ8
Now Trying to do the same with JDK8 + MQ8 , MQServer8 and MQSeriesGSKit-8.0.0-4.x86_64 installed , but now issue with creating certificate with runmqckm command
export LD_LIBRARY_PATH=/opt/mqm/gskit8/lib64
export PATH=$PATH:/opt/mqm/gskit8/bin
runmqckm
bash: runmqckm: command not found
partially Worked with runmqakm
But failed to create jks files as below
runmqakm -keydb -create -db /var/mqm/qmgrs/TLSTEST\!QM/ssl/key.jks -pw password -type jks
CTGSK3017W The database type "jks" is not recognized.
Resolved
No Need to set below path
export LD_LIBRARY_PATH=/opt/mqm/gskit8/lib64
export PATH=$PATH:/opt/mqm/gskit8/bin
IBM MQ Fix Pack 7.1.0.7 released November 19th 2015 includes the following APAR:
IV73396: DEPRECATION OF SSLV3 CIPHERSPECS IN WEBSPHERE MQ V7 QUEUE MANAGERS
PROBLEM DESCRIPTION:
Once this change is applied, any queue managers created will disallow the use of the following CipherSpecs on channel definitions associated with the queue manager:
AES_SHA_US
RC4_SHA_US
RC4_MD5_US
TRIPLE_DES_SHA_US
DES_SHA_EXPORT1024
RC4_56_SHA_EXPORT1024
RC4_MD5_EXPORT
RC2_MD5_EXPORT
DES_SHA_EXPORT
NULL_SHA
NULL_MD5
FIPS_WITH_DES_CBC_SHA
FIPS_WITH_3DES_EDE_CBC_SHA
Attempting to use or configure one of these CipherSpecs will result in one or more of the following messages in the queue manager error log: AMQ8242, AMQ9616, AMQ9635.
This was a result of SSLv3 being formally deprecated in June 2015 as a result of the IETF approving and publishing RFC7568
Introduction
Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3.
The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows.
There is a very good IBM developerWorks blog post "SSL and TLS Cipher Specification Deprecations for the MQ Product" posted May 19 2016 by Miguel A. Rodriguez that goes into detail about which ciphers are deprecated in various Fix Packs.
I would recommend that you find a supported TLSv1.2 cipher to use that is compatible with both the Java client and the IBM MQ SVRCONN channel. There were many updates as a result of SSLv3 being deprecated which opened up more TLS ciphers to Java clients using either IBM or Non-IBM JREs.
A good write up about the changes IBM made to the Java client cipher support is IBM developerWorks blog post "MQ Java, TLS Ciphers, Non-IBM JREs & APARs IT06775, IV66840, IT09423, IT10837 -- HELP ME PLEASE!" posted on June 9th 2016 by Tom Leend.
The reason you do not have a problem with IBM MQ v6.0.2.12 is because that version has been out of support for over four years (since September 30th 2012) and IBM would not release any security updates for a End of Service version like it does for supported versions.
I would recommend that you move to a supported version of IBM MQ. When considering which version to upgrade to, note that two of the currently supported versions will be going out of support over the next 16 months:
MQ v7.1 goes out of support in less than four months on April 30th 2017.
MQ v7.5 goes out of support on April 30th 2018.
MQ v8.0 and v9.0 do not have currently announced end of support dates.
IBM developerWorks blog post "MQ Java, TLS Ciphers, Non-IBM JREs & APARs IT06775, IV66840, IT09423, IT10837 -- HELP ME PLEASE!" states that APAR IV66840 which added the useIBMCipherMappings setting is included in 7.1.0.7 and this should allow the use of TLSv1.2 Cipherspecs with a Oracle JRE.
The table in the APAR IV66840 has this information:
The following WebSphere MQ CipherSuite to CipherSpec mappings have
been enabled by this APAR for WebSphere MQ v7.1 and v7.5 where the
classes for Java and classes for JMS support SHA-2:
Oracle CipherSuite IBM MQ CipherSpec
TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
If you compare that to the v7.1 Knowledge center page Specifying CipherSpecs, you find that all three of those are TLSv1.2 Cipherspecs.
For comparison with the IBM JRE Ciphersuite name, the v7.1 Knowledge center page SSL CipherSpecs and CipherSuites in WebSphere MQ classes for Java lists a similar mapping:
IBM CipherSuite IBM MQ CipherSpec
SSL_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA256
SSL_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
UPDATE (2017/01/27) to address further questions
The MQ CipherSpec TLS_RSA_WITH_RC4_128_SHA256 is not one of those listed in APAR IV66840 has having been enabled for non-IBM JREs under MQ v7.1, it is only listed under v8.0. Above I listed the three TLSv1.2 CipherSpecs that were added to MQ v7.1.
I would suggest you try TLS_RSA_WITH_AES_256_CBC_SHA256 as the CipherSpec on the MQ channel and TLS_RSA_WITH_AES_256_CBC_SHA256 as the Java CipherSuite.
The settings below should work with the my suggested CipherSpec/CipherSuite, please note that I changed it from TLSv1 to TLSv1.2
SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
-Dcom.ibm.mq.cfg.preferTLS=true
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
UPDATE (2017/01/30) to try and address further questions
In your question you mention these jar files in your classpath: /tmp/mqssl/com.ibm.mq.jmqi.jar:/tmp/mqssl/com.ibm.mq.jar
Will you please confirm which version of the IBM MQ product each of these are from, you can do this on linux with the unzip utility:
unzip -p com.ibm.mq.jar META-INF/MANIFEST.MF|grep Implementation-Version
Output will be:
Implementation-Version: x.x.x.x - pxxx-xxx-YYMMDD
UPDATE (2017/01/31) to address further questions
APAR IV66840 which includes the -Dcom.ibm.mq.cfg.useIBMCipherMappings=false setting is not included in MQ until v7.1.0.7, this is the version you stated is being used.
Based on the output you provided the jar files you are referencing are from a v7.1.0.1 install which does not include support for TLS on non-IBM JREs such as Oracle JRE.
You also note that the jar files are in /tmp/mqssl, please note that prior to v8 of MQ IBM does not support copying the jar files outside of the default location where they are installed.
IBM Technote "Supported way to install WebSphere MQ Java jar files, JMS jar files, or C/C++ libraries" states:
+++ Section 1: MQ 7.x
The only supported way to get the MQ jar files or the MQ C/C++ library files onto a system is to install either:
the WebSphere MQ product or
the WebSphere MQ Client SupportPacs.
To legally download and use a client you must first accept the terms and conditions specified in the License Agreement.
Do not copy the WebSphere MQ jar files to application EAR or WAR files.
Do not copy the WebSphere MQ jar or MQ C/C++ library files from other machines:
Fix Packs cannot be applied to an "installation" where jar or C/C++ library files have been copied from another machine, and this makes it much more difficult to ensure that all of these jar/library files are kept in step with each other, and are at compatible levels.
Copying jar/library files between machines can also result in multiple copies of the files residing on the same machine, which can cause problems servicing the code and debugging problems.
If your application is on the same server as the MQ v7.1.0.7 Queue Manager then you can just reference the jar file that are in the directory /opt/mqm/java/lib.
If your application is not on the same server and you plan to stay with v7.1 or go with v7.5 I would recommend installing the latest full client install, see my note above on suggestions for versions based on when they are End of Service.
If you decide to go with v8 or v9, IBM Technote "Supported way to install WebSphere MQ Java jar files, JMS jar files, or C/C++ libraries" also states:
b) Starting with MQ 8.0.0.4, you can use Redistributable files:
Installation scenarios for MQ 8.0 and 9.0 in Linux and Windows - Chapter 8: You need to redistribute MQ runtime libraries with your application.
How to download the MQ 8.0.0.4+ and MQ 9.0.0.x redistributable client images for Linux x86-64 and Windows 64-bit
Bitesize Blogging: MQ 8.0.0.4 Redistributable Clients
What this means is that with v8.0.0.4 and higher you can download a MQ JMS and Java only redistributable client.
The MQ JMS and Java only redistributable client client packages are available from FixCentral here.
UPDATE (2017/01/31 A) to address further questions
After searching on the error you are receiving I found this dW Answers post "Why do I get AMQ9771, 2393 SSL Initialization error from a MQ Java/JMS application when trying to use an TLS AES 256 cipher?". It states that the following:
In this case, the issue is caused by attempting to use AES 256 strong
cipher algorithms.
Most Java JREs, including Oracle/Sun and IBM's have Import Limits on
Cryptographic Algorithms enabled. This limits the maximum key sizes
and also some algorithms.
When trying to use a AES 256 cipher, such as
ECDHE_RSA_AES_256_CBC_SHA384 or TLS_RSA_WITH_AES_256_CBC_SHA256 with a
MQ Java/JMS application, you need to ensure your JRE supports this
cipher. In most cases, when the stronger cipher algorithms are needed,
such as AES 256 ciphers, the JCE Unlimited Strength Jurisdiction
Policy Files must be obtained and installed in the JDK/JRE.
This is noted in the JDK/JRE documentation: For Oracle 1.7:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
The link above to the oracle site states:
If stronger algorithms are needed (for example, AES with 256-bit
keys), the JCE Unlimited Strength Jurisdiction Policy Files must be
obtained and installed in the JDK/JRE.
It is the user's responsibility to verify that this action is
permissible under local regulations.
I would suggest that you either use the lower CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256, or follow the advise above to obtain and install the JCE Unlimited Strength Jurisdiction Policy Files.
UPDATE (2017/02/01) to address further questions
The error that caught my eye was Caused by: java.security.NoSuchAlgorithmException: SHA224withRSA Signature not available.
I searched on google for this and found the following dW Answers post "How to resolve issue with MQ v7.x Java client getting SSL error NoSuchAlgorithmException: SHA224withRSA Signature not available?" which states the following:
Assuming using Oracle JVM:
We have found that the root cause of the issue is the signature
algorithm SHA224withRSA is not supported by Oracle JRE 1.7, see
signature algorithms available:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
In the above link the table of interest is under "The SunRsaSign Provider" which lists the following supported signature algorithms:
MD2withRSA
MD5withRSA
SHA1withRSA
SHA256withRSA
SHA384withRSA
SHA512withRSA
Note that SHA224withRSA is not on the list.
The same dW Answers post goes on to state:
This signature algorithm is available in the IBM JVM and also in
Oracle JVM 1.8.
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
In the above link the table of interest is under "The SunRsaSign Provider" which lists the following supported signature algorithms:
MD2withRSA
MD5withRSA
SHA1withRSA
SHA224withRSA
SHA256withRSA
SHA384withRSA
SHA512withRSA
Note that SHA224withRSA is on the list.
Recommendations from the dW post:
Try with Oracle Java 8 (1.8)
Try with IBM Java
UPDATE (2017/02/01 B) to address further questions
Taking into account all of the information gathered through the troubleshooting above the answer is that it is not possible to use a TLSv1.2 cipher with a Oracle Java less than 8 using MQ v7.1.0.7 MQ Java client.
Based on the last dW Answers post I provided, IBM suggested trying with MQ v8, but I do not think they tested this configuration so it may also not work.
If you do want to try with MQ v8 I would suggest you go with the latest v8.0.0.5 Java only redistributable client client packages which I provided links already.
I'm using MySQL 5.7.10 with SSL enabled and certificates generated as per these instructions. My Java 7 application uses a MariaDB Connector/J and SSL is enabled in the JDBC URL:
jdbc:mysql://dbservername:3306/dbname?useSSL=true&trustServerCertificate=false
But the connection fails with:
Caused by: java.lang.RuntimeException: Could not generate DH keypair
...
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of
64, and can only range from 512 to 1024 (inclusive)
According to this blog post, the problem could be resolved by:
Upgrading to Java 8 (or higher).
Downgrading to MySQL 5.7.5 (or lower).
Excluding Diffie-Hellman (DH) ciphers.
(1) isn't an option on the project I'm working on. (2) seems restrictive and would prevent access to future MySQL improvements. (3) seems the most promising: I've verified it does work with MySQL connector/J but unfortunately its GPL license prevents me from being able to use it on my project.
Does MariaDB Connector/J have an equivalent property to enabledSSLCipherSuites or is there any other way to prevent it from using DH ciphers when connecting?
The requested feature options have now been implemented in MariaDB Connector/J version 1.5.0-RC:
enabledSslProtocolSuites Force TLS/SSL protocol to a specific set of
TLS versions (comma separated list). Example : "TLSv1, TLSv1.1,
TLSv1.2" Default: TLSv1, TLSv1.1. Since 1.5.0
enabledSslCipherSuites Force TLS/SSL cipher (comma separated list).
Example : "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384" Default: use JRE ciphers. Since
1.5.0
(See the comments below the question, the release notes and this Jira ticket.)
I have a VM running a Weblogic Server (running version 10.3.6) with 2 nodes. I also have a Tomcat server running on my host machine which runs an SSL web service, that the Weblogic Server has to connect to. I added the two startup parameters to the "Arguments" text area under startup:
-Dweblogic.security.SSL.protocolVersion=TLSv1.1
-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1
I added these since the nodes were trying to connect using SSLv2 before, and causing a handshake error with Tomcat.
After adding these parameters, I still see the nodes trying to connect to Tomcat using SSLv2. I'm trying to get it to use TLS. What else can I do to get it to use TLS?
You're probably not using SSLv2, but an SSLv3 or TLS1.x ClientHello wrapped into an SSLv2 ClientHello. See "Why does Java's SSLSocket send a version 2 client hello?" or "How to initiate ssl connection using SSLv2".
Note that the latest JSSE Reference Guide (JDK 8) says:
Note: As part of disabling SSLv3, some servers have also disabled SSLv2Hello, which means communications with SSLv2Hello-active clients (e.g. JDK 1.5/6) will fail. Starting with JDK 7, SSLv2Hello default to disabled on clients, enabled on servers.
The Java 7 release notes also say:
SSLv2Hello disabled by default on the client: In Java SE 7, SSLv2Hello is removed from the default enabled protocol list on the client.
It's possible that you're using an older JRE or that for whatever reason, SSLv2Hello was explicitly enabled on your clients.
The protocolVersion value should be TLS1 instead of TLSv1.1.
https://docs.oracle.com/middleware/1213/wls/SECMG/ssl_version.htm#SECMG636
Setting -Dweblogic.security.SSL.minimumProtocolVersion=TLSv0 as java option, will set the minimum protocol to SSLV3 and will eliminate the use of SSLV2.
This worked for me.
TLSv0 is invalid, and WebLogic 12.1.3 will set SSLV3 as minimum.
What is the Java version that you're using with WebLogic?
TLS 1.1 is available at Java 1.6 Update 111. That might be why it is not working. That using TLSv1 as value