| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SSL enabled client/server B2B interface |
« View previous topic :: View next topic » |
| Author |
Message
|
| belchman |
 Posted: Fri Jul 31, 2020 7:11 am Post subject: SSL enabled client/server B2B interface |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
We have a B2B MQClient/MQServer interface between our MQ server and ExternalEntityA.
ExternalEntityA (black box to me) is an MQClient connecting to MQServer over SvrconnA.
On MQServer, we have 4 signer certs and 2 personal certs.
The personal certs are for internal MQ interfaces and MQ external interfaces. For now, the main reason for the internal cert is to get to the LDAP which requires an SSL interface.
The signers are our internal CA for our internal certs and an external CA (DigiCert, Entrust, etc) for our external certs.
Now to my questions:
For this interface from ExternalEntityA, they assert that the we need to have an externally signed personal cert on our keystore that will be used for them to authenticate us to them.
Aside: That seems odd to me that a remote client makes such assertions to the server in the relationship. But that is just me complaining.
We have the intermediate and root signers on our keystore that they told us we had to have. We also have the different intermediate and root signers on our keystore that signed our external cert.
Aside: This seems odd to me that a remote client makes us have signers on our keystore that are not in the chain of any certs on our keystore.
This ExternalEntityA seems to be hamstringing us. It appears as if we must have the external cert be the default cert that supports this one interface and not the personal cert for the queue manager itself.
I am looking for ideas. I am looking for things that I do not know.
My position is, the MQServer has its personal cert and that cert is the default cert. Any other certs, like this one, to support a specific interface are not the default.
We did try leaving our personal cert as default and having the external cert be applied directly to the svrconn channel but the SSL handshake would complete. The client side ended the conversation.
Any comments, suggestions or educational input are greatly appreciated.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| belchman |
| Posted: Fri Jul 31, 2020 7:15 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
| Quote: |
| We did try leaving our personal cert as default and having the external cert be applied directly to the svrconn channel but the SSL handshake would complete. |
ssl handshake would not complete
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 31, 2020 8:05 pm Post subject: Re: SSL enabled client/server B2B interface |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| belchman wrote: |
The signers are our internal CA for our internal certs and an external CA (DigiCert, Entrust, etc) for our external certs.
Now to my questions:
For this interface from ExternalEntityA, they assert that the we need to have an externally signed personal cert on our keystore that will be used for them to authenticate us to them.
Aside: That seems odd to me that a remote client makes such assertions to the server in the relationship. But that is just me complaining.
|
That's expected and that's just you complaining. Get with the program! (SSL 101 )
| belchman wrote: |
We have the intermediate and root signers on our keystore that they told us we had to have. We also have the different intermediate and root signers on our keystore that signed our external cert.
Aside: This seems odd to me that a remote client makes us have signers on our keystore that are not in the chain of any certs on our keystore.
|
Again that's just you complaining. You need the signer certs of their cert in your truststore or the trust chain is incomplete. Get with the program! (SSL 101 )
| belchman wrote: |
This ExternalEntityA seems to be hamstringing us. It appears as if we must have the external cert be the default cert that supports this one interface and not the personal cert for the queue manager itself.
|
That one's a little bit strange. I would have expected you to put the private cert key into the certlabel field of the channel. However if they connect via java, you might have to make it the default cert for the qmgr.
| belchman wrote: |
I am looking for ideas. I am looking for things that I do not know.
My position is, the MQServer has its personal cert and that cert is the default cert. Any other certs, like this one, to support a specific interface are not the default.
We did try leaving our personal cert as default and having the external cert be applied directly to the svrconn channel but the SSL handshake would not complete. The client side ended the conversation.
Any comments, suggestions or educational input are greatly appreciated. |
Review the documentation. I would set the external cert as default qmgr cert this way java apps would see it. Check the documentation, I believe that the java client requires the cert to be the def cert on the qmgr. That might depend on the version of the java client, haven't read the latest about 9.2.0. In any case you could try and have them use the client definition of the channel (ccdt) and see if that changes anything. Enjoy 
_________________
MQ & Broker admin
Last edited by fjb_saper on Sun Aug 02, 2020 6:02 pm; edited 1 time in total |
|
| Back to top |
|
|
| belchman |
| Posted: Sat Aug 01, 2020 2:30 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
| Quote: |
| You need the signer certs of their cert in your truststore or the trust chain is incomplete |
We have the signers of our personal certs and the signers they told us to have on keystore.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Sat Aug 01, 2020 2:38 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Thank you for your time and attention.
| Quote: |
| That one's a little bit strange. I would have expected you to put the private cert key into the certlabel field of the channel. However if they connect via java, you might have to make it the default cert for the qmgr. |
Aside from the complaining, this is my main beef. This queue manager will be an outlier in which it is the only one of hundreds that will have a personal cert that is not our internal cert as the default.
I don't know anything about the remote client and if it is Java or not.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Aug 01, 2020 4:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| belchman wrote: |
| ...I don't know anything about the remote client and if it is Java or not. |
Check the channel status when it lights up - one of the attributes is RPRODUCT and should return the application type, with RVERSION returning the version being used.
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
