ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » IBM MQ SSL/Cypher

Post new topic  Reply to topic
 IBM MQ SSL/Cypher « View previous topic :: View next topic » 
Author Message
m4rcoschmucki
PostPosted: Thu May 20, 2021 4:59 am    Post subject: IBM MQ SSL/Cypher Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu May 20, 2021 6:01 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu May 20, 2021 6:02 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu May 20, 2021 9:08 pm    Post subject: Re: IBM MQ SSL/Cypher Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
tczielke
PostPosted: Fri May 21, 2021 4:07 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
exerk
PostPosted: Fri May 21, 2021 6:41 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Fri May 21, 2021 11:48 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
fjb_saper
PostPosted: Sat May 22, 2021 11:09 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
tczielke
PostPosted: Sat May 22, 2021 11:59 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
PeterPotkay
PostPosted: Sat May 22, 2021 5:01 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
m4rcoschmucki
PostPosted: Thu Jun 24, 2021 12:43 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Jun 24, 2021 1:22 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » IBM MQ SSL/Cypher
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.