| Author |
Message
|
| tonynix |
 Posted: Thu May 11, 2017 7:28 am Post subject: Any ideas on how to demo MQ TLS from a Win10 to a zOS QMGR? |
 |
|
Novice
Joined: 18 Jan 2017
Posts: 10
|
Hi everyone,
Can you give me some ideas or recommendations on how best to demo a message sent from a Win10 client to a z/OS QMGR? I need to use TLS from the client to z/OS. I've used IBM File Manager to put a message into the z/OS QMGR, but haven't found an easy way to demo writing a message in Win10 and sending it to a TLS-configured QMGR. TIA for any ideas you can give me. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu May 11, 2017 8:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What have you tried? What were the results?
It's the usual MQ channel configuration with certs at both ends.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu May 11, 2017 8:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
IH03 SupportPac, CCDT, CMS-type key store for the 'client'. You'll need the signer certs your site uses for the z/OS queue manager, and a personal cert for the CMS-type key store. Use the IBM Key Management GUI on the Windows machine to create the key store and personal cert request. The CCDT can be created on the Windows machine too, if you're using MQ V8.0 or greater.
_________________
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 |
|
|
| tonynix |
| Posted: Mon May 22, 2017 12:29 pm Post subject: |
|
|
Novice
Joined: 18 Jan 2017
Posts: 10
|
| HI. I had some success proving the SSL/TLS setup from MQ Explorer by put a message into a queue on a single queue manager. I was also able to set up a TLS connection between two different queue managers on two separate LPARS by defining a remote queue, putting a message into the remote queue, and getting the message on the second queue manager. I've used the same SSLCIPH value on both the sender and receiver sides of the transport channel. The techie in me wants to "prove it", so I'm also looking for a way to show that SSL is definitely working. Today, I tried removing SSLCIPH from the sender side of the channel and z/OS was giving me CSQX639E and CSQX641E errors. When I changed the sender side to a different SSLCIPH value from the receiver side, I then received CSQX631E errors. IBM MQ doc confirms that MQ expects the same SSLCIPH designation on both sides of the channel. But, I'm wondering if that's good enough. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 22, 2017 12:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Depends on what you mean by "prove".
In theory, the deepest proof you can show is that the packets are encrypted passing across the channel.
But if you/your customer trusts TLS to do that, then all you need to show is that you can configure a. channel with TLS, and it runs, and that if you configure it wrong, then it doesn't.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| exerk |
| Posted: Mon May 22, 2017 12:59 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Get the channel running with SSL/TLS then issue a DIS CHS(<CHL NAME>), which will show the certificate values being flowed (both personal and SSLCERTI), and the cipher spec in use. If whomever requires proof deems that to be unacceptable then as mqjeff suggests, wireshark it.
_________________
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 |
|
|
| tonynix |
| Posted: Mon May 22, 2017 2:05 pm Post subject: |
|
|
Novice
Joined: 18 Jan 2017
Posts: 10
|
| Thanks @exerk. I'll ask my IT department to wireshark it too, but the CHSTATUS looks like it confirms the configuration. |
|
| Back to top |
|
|
|
|
