Windows IIS Server 10 supported TLS_AES_256_GCM_SHA384 on TLS 1.3.
But my application max TLS version TLS 1.2 . I can't send request to server due to tls mismatch.
TLS_AES_256_GCM_SHA384 is not found in my app. How can I use this CipherSuite ?
Note : My android project language is Java.
The TLSv1.3 approach to ciphers isn't directly compatible with TLSv1.2, because the key exchange and signature is now treated separately (which means you can't just use a TLSv1.3 cipher in TLSv1.2 and conversely).
You can though pick equivalent ciphers for TLSv1.2 that match the functionality of TLSv1.3. All the options are listed on the IEEE site here.
If however all you are looking for is a strong set of options that support both TLSv1.3 and TLSv1.2, then I'd recommend taking a look at the Mozilla SSL configuration generator, which makes the process trivial to follow.
I am stuck with a problem with Java security setting preventing my Dataproc cluster (Image 2.0.32-debian10) running PySpark to connect to SQL Server 2019 with Spark/JDBC connector (spark:spark.jars.packages=com.microsoft.azure:spark-mssql-connector_2.12:1.2.0 and sqljdbc4-2.0.jar). It seems the security level of the cluster and SQL Server 2019 (running on a GCE) do not match and there is this SSL/TLS error during handshake.
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver
could not establish a secure connection to SQL Server by using Secure
Sockets Layer (SSL) encryption. Error: "No appropriate protocol
(protocol is disabled or cipher suites are inappropriate)".
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1412)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1058)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:833)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:716)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:841)
I could bypass this by using Jupyter Notebook to directly modify "Local Disk/usr/lib/jvm/temurin-8-jdk-amd64/jre/lib/security/java.security" and comment out this part of the code "jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA,
DH keySize lessThan 1024, EC keySize lessThan 224, 3DES_EDE_CBC, anon, NULL,
include jdk.disabled.namedCurves", and I will be able to connect to SQL Server successfully.
However this would work only if my Dataproc cluster is a single node cluster. If it's a standard cluster (e.g. 1 master+2 workers), it seems the node doesn't recognize this change in security properties and I faced the same error as before (perhaps because the job is distributed to a worker node which does not recognize the change in java.security in the master node local disk).
I tried passing these as the cluster properties hoping it would apply the change in security properties to worker nodes as well:
spark:spark.driver.extraJavaOptions='-Djava.security.properties==gs://greenline-demo-341617-spark-src/Demo/02_Microsoft_SQL/java.security',spark:spark.executor.extraJavaOptions='-Djava.security.properties==gs://greenline-demo-341617-spark-src/Demo/02_Microsoft_SQL/java.security'
But I'm stuck at this error instead 🤣
Exception in thread "main" java.lang.InternalError: internal error:
SHA-1 not available.
at sun.security.provider.SecureRandom.init(SecureRandom.java:108)
at sun.security.provider.SecureRandom.(SecureRandom.java:79)
at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:198)
at java.security.SecureRandom.(SecureRandom.java:162)
at java.util.UUID$Holder.(UUID.java:96)
at java.util.UUID.randomUUID(UUID.java:142)
Connection string url_db = "jdbc:sqlserver://10.148.xx.xx:1433;databaseName=AdventureWorks2019;sslProtocol=TLSv1;encrypt=false"
I would like to connect to my database instance using TLS1.2 from a Linux instance and I am unable to do so.
I am using the following configuration
Java JDK : Amazon corretto openjdk version : "1.8.0_252"
JDBC driver : Microsoft SQL server mssql-jdbc:8.2.2.jre8
Connection string : jdbc:sqlserver://[my database url]:1433;SSLProtocol=TLSv1.2
Operating system: Amazon Linux
Database: Microsoft SQL Server 16 running on a Windows machine
I have turned off TLS1 and TLS1.0 on the database to force my java application to use only TLS1.2
The following error appears when my application tries to connect to the database:
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: No appropriate protocol (protocol is disabled or cipher suites are inappropriate).
This maybe not the best solution but to get my application working i used,
java.security.Security.setProperty("jdk.tls.disabledAlgorithms","SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024,EC keySize < 224, 3DES_EDE_CBC, anon, NULL");
I upgraded from Java 8.0.202 to 8.0.291 and got the issue you have mentioned which had disabled TLS 1.0 and 1.1. The property i have set above are the settings from Java 8.0.202
This issue seen after java upgrade:
LDAP with DNS alias does not connect with java 11.0.2 where as it worked
with java 8
DNS alias as below this remain same no change here only change is java upgrade 8 to 11:
$ nslookup ad1.XXXXX.zz
Server: 10.222.249.209
Address: 10.222.249.209#53
Name: ad1.XXXXX.zz
Address: 10.222.249.205
Name: ad1.XXXXX.zz
Address: 10.222.249.204
Name: ad1.XXXXX.zz
Address: 10.222.249.210
LDAP direct IP with java 11.0.2 it works no issue:
$ nslookup qdegsf.XXXXX.zz
Server: 10.222.249.209
Address: 10.222.249.209#53
Name: qdegsf.XXXXX.zz
Address: 10.222.249.210
Process parameters:
/opt/3rdparty/jdk_installed/jdk-11.0.2/bin/java -Dsserver -Djdk.serialFilter=* -Dfile.encoding=UTF8 -Djavax.net.ssl.trustStore=/opt/3rdparty/tomcat/conf/svrtrust -Djavax.net.ssl.trustStorePassword=XXXX -Djavax.net.ssl.keyStore=/opt/3rdparty/tomcat/conf/svrkeystore.jks
Below is the issue traces when ldap connection is made
java.lang.RuntimeException: connection to ldap server failed;url;ldaps://ad1.XXXXX.zz:636;authDN;sa_XXX#XXXXX.zz
javax.naming.CommunicationException: simple bind failed: ad1.XXXXX.zz:636 [Root exception is java.net.SocketException: Connection or outbound has closed]
java.net.SocketException: Connection or outbound has closed
Trace for the thrown exceptions:
java.lang.RuntimeException: connection to ldap server failed;url;ldaps://ad1.XXXXX.zz:636;authDN;sa_XXX#XXXXX.zz
at auth.ldap.LdapConnection.testConnection(LdapConnection.java:46)
Caused by: javax.naming.CommunicationException: simple bind failed: ad1.XXXXX.zz:636 [Root exception is java.net.SocketException: Connection or outbound has closed]
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
at java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
at auth.ldap.LdapConnection.testConnection(LdapConnection.java:41)
... 3 more
Caused by: java.net.SocketException: Connection or outbound has closed
at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:976)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
... 15 more
javax.naming.CommunicationException: simple bind failed: ad1.XXXXX.zz:636 [Root exception is java.net.SocketException: Connection or outbound has closed]
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
at java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
at auth.ldap.LdapConnection.testConnection(LdapConnection.java:41)
Caused by: java.net.SocketException: Connection or outbound has closed
at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:976)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
... 15 more
java.net.SocketException: Connection or outbound has closed
at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:976)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
at java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
at nims.auth.ldap.LdapConnection.testConnection(LdapConnection.java:41)
at auth.LdapAuthenticationService.doTestConnection(LdapAuthenticationService.java:50)
> Update getting below error when :
$ openssl s_client -connect ad1.XXXXX-ru.zz:636
CONNECTED(00000003)
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=27:certificate not trusted
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
0 s:
i:/DC=zz/DC=XXXXX-ru/CN=XXXXX-ru-ROOT-CA
Server certificate
-----BEGIN CERTIFICATE-----
MIIFfjCCBGagAwIBAgITLwAAAKgllUHEZUjzRwAAAAAAqDANBgkqhkiG9w0BA.................
APpwNrloBJjZo2bJ7pqe4gXN
-----END CERTIFICATE-----
subject=
issuer=/DC=zz/DC=XXXXX-ru/CN=XXXXX-ru-ROOT-CA
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
SSL handshake has read 1980 bytes and written 441 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: C51900006745E495E1C8CA132C0EDF901C3638DE9E5EEA506551E298E2374372
Session-ID-ctx:
Master-Key: A8B4C4E2B01FE11822CE047D3B7D692EE1C001DA551DFE63FBC314737177BE7A285F79D6FF36B67D3E1AFF72C1402D2D
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1574232095
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
Please provide suggestion .
Thanks
Depending on the version of Java 8 you were using, there could be several reasons for this error:
Java 11 (and recent versions of Java 8) now enforce hostname
verification when establishing SSL connections. So the server's
certificate much match the hostname you are trying to connect to.
Java 11 also has newer cipher suites and TLS versions, and deprecated some old cipher suites. You may want to enable SSL
debugging to see what is exchanged on the SSL layer.
Finally, there are several issues with TLS(1.3), cipher suites in the early versions of Java 11, so you might want to switch to the
latest update (11.0.5)
You can change default params like RSA keysize etc. by modifying the file java.security. However, please be aware that there is a second file java.config (on Linux it is located: /etc/crypto-policies/back-ends/java.config) that overrides the params in java.security.
This is controlled by the property (in java.security):
security.useSystemPropertiesFile=true
So, either change that property to false, or modify params directly in java.config.
I was stuck with that for a long time!
wrote a test script to connect with ldap ( with ssl logs enable) # jdk 11
/opt/soft/jdk_installed/jdk-11.0.2/bin/java -XX:+UseSerialGC -DLdapsConnect -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/opt/soft/tomcat/conf/svrtrust -Djavax.net.ssl.trustStorePassword=hsqlIiza -Djavax.net.ssl.keyStore=/opt/soft/tomcat/conf/svrkeystore.jks -Djavax.net.ssl.keyStorePassword=hsqlIiza -classpath /tmp/ LdapsConnect $*
found that below error in ssl logs
javax.net.ssl|ERROR|1D|Thread-0|2020-01-22 10:55:21.632 CET|TransportContext.java:313|Fatal (CERTIFICATE_UNKNOWN): No subject alternative DNS name matching ad1.xxxx.zz found.
Conclusion/Solution : Ldap certificate should be modified to have ad1.ngssm-ru.zz which is missing.
As Java 8u181 has changes as below in ldap support which does not allow old way after java version 8u181 and above.
Java is trying to make sure the host name in your connection configuration matches the host names in the remote LDAPS TLS server certificate and that those host names in the certificate are valid. The correct solution for a secure connection is to have your LDAP server administrators correct the LDAPs certificate the ldap server is using so that the improved endpoint identification algorithms work. This is for our protection.
https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html
Changes
core-libs/javax.naming
? Improve LDAP support
Endpoint identification has been enabled on LDAPS connections.
To improve the robustness of LDAPS (secure LDAP over TLS) connections, endpoint identification algorithms have been enabled by default.
Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.
Define this system property (or set it to true) to disable endpoint identification algorithms.
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.