Create SVRCONN Channel with SSLCIPH and SSLAUTH that that require for Any client Application to connect to QMGR . prior to this QMGR should have a Keystore configured with a certificate .aaa
How to enable 2-way SSL or 1-Way SSL in IBM MQ ? Failing any steps will get below error .Same with WebSphere weblogic jboss or with a standlone java program .
When a standalone java program tries to connect to WebSphere MQ we are getting below error .
MQ Side Error : AMQ9637E: During handshake, the remote partner sent no certificate Client Side Error: A WebSphere MQ Error occured : Completion Code 2 Reason Code 2059 com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2059'. at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:255) at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:450) at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:487) at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:97) at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:194) at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:874) at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:822) at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:764) at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:200) at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:871) at SSLSample.runSample(SSLSample.java:84) at SSLSample.main(SSLSample.java:48) Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9204: Connection to host '127.0.0.1(51414)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2059;AMQ9503: Channel negotiation failed. [3=CLIENT.CON ]],3=127.0.0.1(51414),5=RemoteConnection.analyseErrorSegment] at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:2301) at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1273) at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJmqiImpl.java:377) at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:562) at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:916) at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:240) ... 11 moreWe have tried changing cipher in both channel and client side with TLS_RSA_WITH_AES_256_CBC_SHA256
When SSLAUTH is REQUIRED why MQ is expecting Client to present it certificate ? do we need to Add client root ,intermediate and cert ? or only root and intermediate is enough to add at MQ Side ?
a)
The SSLCAUTH attribute specifies whether the channel needs to receive and authenticate a TLS certificate from a TLS client.
The two possible values for SSLCAUTH are:
OPTIONAL
If the peer TLS client sends a certificate, the certificate is processed as normal but authentication does not fail if no certificate is sent.
REQUIRED
If the TLS client does not send a certificate, authentication fails.
b)
This means that if your SVRCONN channel is configured with SSLCAUTH(REQUIRED), the SSL Client needs to present a certificate to be authenticated by the queue manager.
For this two-way SSL to work successfully, the queue manager needs the CA signer certificates (intermediate/root) of the remote client.
Based on the error snippet you provided, it looks like the client is missing a personal certificate.
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9204:
Connection to host ‘127.0.0.1(51414)’ rejected.
[1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2059;
AMQ9503: Channel negotiation failed.
To try to solve:
a)
If you do not want to enable SSL Client authentication, you can change the SVRCONN channel attribute SSLCAUTH(OPTIONAL).
b)
If you want to enable SSL client authentication SSLCAUTH(REQUIRED), make sure the Client application has a personal certificate.
Then you need to add the CA signers (intermediate/root) of the client to the queue manager’s keystore.
Refresh security type(ssl) on the queue manager after making any changes on its keystore.
How do I configure SSL TLS between Java client and MQ queue manager?
To setup SSL/TLS between MQ queue manager and MQ Java program(using 3rd party CA-signed certificates)
Primarily, 2 things need to be setup correctly for an SSL/TLS connection to be successful.
- both sides of the connection need correct certificate keystores/truststores with the appropriate certificates in place.
- for MQ both sides of the connection MUST specify a matching cipher when starting the communication. For Java this can be tricky, due to cipherspec/ciphersuite naming conventions, and also depends on the Java JRE vendor and ciphersuite support.
From Java client side, its important to know..- what version of MQ Java/JMS classes/client is being used.- what version/vendor Java/JRE is being used (IBM’s or Oracles/Hotspot, etc)
- Java uses JKS-type (.jks) keystore, whereas MQ used CMS-type (.kdb) keystore
- Java uses ciphersuite whereas MQ uses cipherspec (there is a mapping from ciphersuite to cipherspec built into MQ client jars)
1st part is making sure that the certificates and keystoresare setup correctly.
Example:Setup queue manager QM1:
// Create, prepare MQ qmgr
crtmqm QM1strmqm QM1
runmqsc QM1
in runmqsc, create listener, channels, queues, etc.. (make sure listener port is unique)
DEFINE LISTENER(LIST1) TRPTYPE(TCP) PORT(2014) CONTROL(QMGR)START LISTENER(LIST1)
DEFINE CHANNEL(CHAN1) CHLTYPE(SVRCONN) SSLCAUTH(OPTIONAL)DEFINE QLOCAL(Q1)
DEFINE CHANNEL(CHAN2) CHLTYPE(SVRCONN) SSLCAUTH(OPTIONAL) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA)
// if MQ v7.1 or higher, disable CHLAUTH and CONNAUTH (v8) to test
ALTER QMGR CHLAUTH(DISABLED) CONNAUTH (‘ ‘)REFRESH SECURITY TYPE(CONNAUTH)
// QMGR and Listener should be RUNNING and ready.Setup queue manager certificate and keystore repository
// goto qmgrs//ssl directory:
(linux as mqm user)cd /var/mqm/qmgrs/QM1/ssl.runmqckm -keydb -create -db key.kdb -type cms -pw passw0rd -stash.// CA-signed…runmqckm -certreq -create -db key.kdb -pw passw0rd -label ibmwebspheremqqm1 -dn “CN=qm1,O=IBM,C=US” -size 2048 -file qm1.req -sig_alg SHA256_WITH_RSA
// Note that the qmgr personal certificate label name is following// recommended default labelname
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q014340_.html .// send file ssl1.req to CA to get signed..// CA provides signed request + CA signer certificates, which need to be added to keystore, and exchanged to remote partner.// add CA root and any CA intermediate signer certificates (do NOT use add on Signed request).runmqckm -cert -add -db key.kdb -pw passw0rd -label label -file.https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q012830_.html// receive signed cert file (from CA) to kdb with runmqckm -cert -receive(this merges existing private key in kdb.. with the signed cert request from CA).runmqckm -cert -receive -file -db key.kdb -pw passw0rd(where is signed request file from CA).https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q012800_.htmlThen use the runmqckm commands to ensure you have a personal certificateand all the CA signer certificates.// list personal certsrunmqckm -cert -list personal -db key.kdb -pw passw0rd
// list ca-signer certsrunmqckm -cert -list ca -db key.kdb -pw passw0rdJava client certificate and JKS keystore:
Setup Java JKS keystore/truststore repository and certificate.# create this in some directory..
runmqckm -keydb -create -db javaclient.jks -type jks -pw passw0rd.// CA-signed…runmqckm -certreq -create -db javaclient.jks -type jks -pw passw0rd -label javaclientcert -dn “CN=client,O=IBM,C=US” -size 2048 -file client.req -sig_alg SHA256_WITH_RSA.// send file client.req to CA to get signed..// CA provides signed request + CA signer certificates, which need to be added to keystore, and exchanged to remote partner.
// add CA root and any CA intermediate signer certificates (do NOT use add on Signed request).runmqckm -cert -add -db javaclient.jks -pw passw0rd -type jks -label -file.https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q012830_.html// receive signed cert file (from CA) to jks with runmqckm -cert -receive(this merges existing private key in jks.. with the signed cert request from CA).runmqckm -cert -receive -file -db javaclient.jks -pw passw0rd -type jks(where is signed request file from CA).https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q012800_.htmlThen use the runmqckm commands to ensure you have a personal certificateand all the CA signer certificates.// list personal certsrunmqckm -cert -list personal -db javaclient.jks -pw passw0rd -type jks
// list ca-signer certsrunmqckm -cert -list ca -db javaclient.jks -pw passw0rd -type jksExchange CA signer (Intermediate and Root certificates) between the qmgr and Java client’s keystore..
// Java requires a truststore for this.// you can use the same .jks file for both the truststore and keystore,// or you can make separate keystore and truststore.jks files.
// for this example, we will use the same javaclient.jks for// both the Java keystore and truststore.
// list the certs on both side again, to ensure/verify you have// the needed CA certificates and personal certificates on both sides.
At this point, the keystores and certificates should be correct.
On the MQ qmgr,in runmqsc for the qmgr:
DISPLAY QMGR SSLKEYR
make sure that SSLKEYR on qmgr matches fullpath and BASE filename of the keystore.. (without file extensions)ie default for qmgr QM1SSLKEYR(/var/mqm/qmgrs/QM1/ssl/key)
If you named the qmgrs keystore differently, you needto alter the SSLKEYR value to match (be careful not touse file extension).
After any changes to the queue manager’s keystoremake sure to issue in runmqsc:
REFRESH SECURITY TYPE(SSL)
this reloads the keystore and any changes.
For you Java client program – Specify certificate keystore/truststore
You must specify the keystore and truststore filesand passwords to these. This can be done via JVMsettings or via code:
examplesfor JVM settings:-Djavax.net.ssl.trustStore=javaclient.jks-Djavax.net.ssl.trustStorePassword=password-Djavax.net.ssl.keyStore=javaclient.jks-Djavax.net.ssl.keyStorePassword=password
SSLCAUTH(REQUIRED) does this means 2 -way ssl enabled in MQ ? in this case do we need client root and intermediate should present on the QMGR keystore ?
what is the configuration for 1 -way ssl in QMGR ?
a)> what is the configuration for 2-way ssl in QMGR ?
> SSLCAUTH(REQUIRED) does this means 2 -way ssl enabled in MQ ? in this case do we need client root and intermediate should present on the QMGR keystore ?
Yes, SSLCAUTH(REQUIRED) means two-way TLS/SSL. The MQ client needs a personal certificate and the queue manager needs the CA signers (intermediate and root) of the MQ client.
b)
> what is the configuration for 1 -way ssl in QMGR ?
For this configuration you would set SSLCAUTH(OPTIONAL).
This means the MQ client does not need a personal certificate, hence the queue manager does not need any CA signers (root and intermediate) from the MQ client.
The channel still configured with TLS by providing a CipherSpec, the only difference is that the MQ Client is not presenting a certificate.
c)
> In the earlier MQ versions we don’t need to add any client certificate signers onto QMGR keystore . is it a new change in 9.1 ?
This is not a recent change. The SSLCAUTH attribute exists since MQ 6.0. Thus, depending on what value you have configured, either required or optional, would determine one-way or two-way ssl.
In summary:
1) You secure your channel by providing a CipherSpec value in the SSLCIPH channel attribute, regardless of what you choose for SSLCAUTH.
2) Depending on your company’s security policy, you have the option to required the SSL Client to have a personal certificate for mutual authentication or not. This does not affect the channel encryption performed by the CipherSpec.
Conclusion :So when we configure Cipher which means connectivity is over SSL and whether it is 1-way or 2-way will be decided by SSLAUTH parameter .