| Author |
Message
|
| m4rcoschmucki |
 Posted: Thu May 20, 2021 4:59 am Post subject: IBM MQ SSL/Cypher |
 |
|
Newbie
Joined: 20 May 2021
Posts: 2
|
Hi all
I'm using IBM MQ Docker Container and a Java application which sends messages to it. Everything is working if I'm not using SSL/Cypher.
If I'm activate SSL/Cypher, I got the following error:
Client side error (java app):
| Code: |
SSLHandshakeException[Remote host closed connection during
Caused by: java.io.EOFException: SSL peer shut down incorrectly |
Server side error (IBM MQ):
| Code: |
| 2021-05-19T15:21:53.060Z AMQ9654E: Validation checks for the remote personal certificate failed. The channel did not start. |
I found the issue on the web and the solution is the following:
| Quote: |
| Add a personal certificate to the database of the queue manager, that has been signed by a certificate in the truststore of the client, and which has a label of the form ibmwebspheremqqm<qmgr_name>. |
... but I have the certificate under the following path, and this certificate is signed by truststore of the client and it doesn't work:
| Code: |
| /etc/mqm/pki/keys/ibmwebspheremqqmqm1/ibmmq.crt |
I really need help to get it worked with the SSL encryption!
Thank you for your feedback.
Regards,
marco |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu May 20, 2021 6:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
In you queue manager key store you require:
1. The CA certificates from the organisation that signed the queue manager's personal certificate;
2. The personal certificate of the the queue manager;
3. The CA certificates from the organisation that signed the remote application's personal certificate.
The remote application will require (assuming it has separate TRUST and CERTIFICATE stores, but they can be combined into one):
CERTIFICATE STORE
1. The personal certificate of the application.
TRUST STORE
1. The CA certificates from the organisation that signed the remote application's personal certificate;
2. The CA certificates from the organisation that signed the queue manager's personal certificate.
You'll find the required key store commands in the IBM Documentation.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu May 20, 2021 6:02 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Moved to the Security forum.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu May 20, 2021 9:08 pm Post subject: Re: IBM MQ SSL/Cypher |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| m4rcoschmucki wrote: |
I found the issue on the web and the solution is the following:
| Quote: |
| Add a personal certificate to the database of the queue manager, that has been signed by a certificate in the truststore of the client, and which has a label of the form ibmwebspheremqqm<qmgr_name>. |
... but I have the certificate under the following path, and this certificate is signed by truststore of the client and it doesn't work:
| Code: |
| /etc/mqm/pki/keys/ibmwebspheremqqmqm1/ibmmq.crt |
|
So you have a certificate signed signed appropriately, but you have not added it to the truststore of the client?
You have not shown us how you tell your application which truststore to use.
Do you know how to add a certificate to the client truststore?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri May 21, 2021 4:07 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| exerk wrote: |
In you queue manager key store you require:
1. The CA certificates from the organisation that signed the queue manager's personal certificate;
2. The personal certificate of the the queue manager;
3. The CA certificates from the organisation that signed the remote application's personal certificate.
The remote application will require (assuming it has separate TRUST and CERTIFICATE stores, but they can be combined into one):
CERTIFICATE STORE
1. The personal certificate of the application.
TRUST STORE
1. The CA certificates from the organisation that signed the remote application's personal certificate;
2. The CA certificates from the organisation that signed the queue manager's personal certificate.
You'll find the required key store commands in the IBM Documentation. |
I would amend the statement as follows. The remote end only needs the root CA of the peer, as the peer will send its personal cert + trust chain to the remote end when properly configured. The reason I bring it up is that this approach can reduce the need for TLS administration of having to put intermediate certs for the personal certs on the remote ends.
In your queue manager key store you require:
1. The CA certificates from the organisation that signed the queue manager's personal certificate;
2. The personal certificate of the the queue manager;
3. The root CA certificate from the organisation that signed the remote application's personal certificate.
The remote application will require (assuming it has separate TRUST and CERTIFICATE stores, but they can be combined into one):
CERTIFICATE STORE
1. The personal certificate of the application properly chained with the trust certs. If this is a JKS, it should be a privateKeyEntry with a chain length > 1. This can be validated with the "keytool list" command.
TRUST STORE
1. The root CA certificate from the organisation that signed the queue manager's personal certificate.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri May 21, 2021 6:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| tczielke wrote: |
| I would amend the statement as follows. The remote end only needs the root CA of the peer, as the peer will send its personal cert + trust chain to the remote end when properly configured. The reason I bring it up is that this approach can reduce the need for TLS administration of having to put intermediate certs for the personal certs on the remote ends... |
I'm a belt-and-braces man (belt-and-suspenders for those across the pond)
 ...
...but yes, you are correct.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri May 21, 2021 11:48 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I am sure there are scenarios where you want to cover yourself and have the intermediate CAs on the remote side, especially if your partner side is not good about sending the personal cert + trust chain in the TLS handshake.
I was recently excoriated by our security team for putting the intermediate CAs of the peers in the remote keystores and also see the administrative benefit of only including the root CAs in the remote keystores, so thought I would pass on the tip.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 22, 2021 11:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In my experience, validation of a personal certificate fails if you do not have its signer chain in the truststore part of the keystore.
By the same token I always put the full signer chain in the truststore. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat May 22, 2021 11:59 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| fjb_saper wrote: |
In my experience, validation of a personal certificate fails if you do not have its signer chain in the truststore part of the keystore.
By the same token I always put the full signer chain in the truststore. |
As long as the remote end sends its personal certificate + the trust chain, the other end just needs the root CA cert in its truststore to trust the personal certificate.
gskit will do this (send the queue manager cert + the trust chain to the client end) as long as you have the trust chain of the queue manager cert in the key.kdb.
For a Java client, this will happen (the client will send its certificate + the trust chain to the queue manager) when there is a privateKeyEntry with a chain length > 1 and this entry includes the trust chain of the client cert.
It is worth going to this model, as you now only need to update the client side when the client cert changes (including any intermediate CA cert changes) and vice versa for any queue manager cert side changes, as long as the root CA for the new certificate does not change. This can significantly reduce TLS administration.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 22, 2021 5:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| tczielke wrote: |
It is worth going to this model, as you now only need to update the client side when the client cert changes (including any intermediate CA cert changes) and vice versa for any queue manager cert side changes, as long as the root CA for the new certificate does not change. This can significantly reduce TLS administration. |
And it adheres to the TLS 1.2 RFC. I read the following passage as its required for the SSL Server (the QMGR) to send the entire chain up to and optionally including the root. If done, that means the SSL Client (the MQ Client) only needs the root in its trust store.
https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2
| Quote: |
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| m4rcoschmucki |
| Posted: Thu Jun 24, 2021 12:43 am Post subject: |
|
|
Newbie
Joined: 20 May 2021
Posts: 2
|
First of all many thanks for your feedback.
But honestly I don't understand the next steps.
I've a certificate and a privatekey (from letsencrypt) in IBM MQ server and the connection through my browser to the IBM-MQ-User-Interface is working with https, so there I've a secure connection.
But how it works to have a secure connection between the application and the IBM-MQ-server? |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 24, 2021 1:22 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| m4rcoschmucki wrote: |
| I've a certificate and a privatekey (from letsencrypt) in IBM MQ server and the connection through my browser to the IBM-MQ-User-Interface is working with https, so there I've a secure connection. |
There you are connecting to a web server, not to the queue manager so the link is different and the process to connect with TLS is different.
| m4rcoschmucki wrote: |
| But how it works to have a secure connection between the application and the IBM-MQ-server? |
To have a secure connection between a Java MQ application and the queue manager itself, you need some different setup steps. These are documented here:
Transport Layer Security (TLS) support in IBM MQ classes for Java
or
Using TLS with IBM MQ classes for JMS
depending on which Java interface your application is using.
You'll also need to put your certificate in a JKS keystore.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
