| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SSL working one way, not the other... |
« View previous topic :: View next topic » |
| Author |
Message
|
| flaufer |
 Posted: Thu Sep 29, 2011 11:47 pm Post subject: SSL working one way, not the other... |
 |
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
Folks,
Im at the end of my (prossibly restricted) wisdome here...
Setup:
Two queuemanagers. One Windows, One Linux.
Two Pair of channels (SDR-RCVR). working fine without SSL.
creating queue manager certificates (witht he proper label). have them signed by their respective CAs (different CAs for each site because different companies) and imported them into the QMGR keystores.
import both of the root CA certificate in both queuemanagers (on our side because we have our own qmgr certificate signed by it, on the peer side to allow the peer to check our certificate which MQ will send during SSL initialization and vice versa).
Now the funny thing.
SDR(Linux) to RCVR(Windows) is working fine. Including SSLPEER setting. CIPHERSPECs have been defined identical. Channel starts. fine.
SDR(Windows) to RCVR(Linux) will not come up. SSLPEER left empty as long as we haven't made it work. CIPHERSPEC identical (check multiple times). SDR goes into retrying and on both ends, we receive AMQ9633.
SSLCAUTH setting does not change the situation (was REQUIRED, changed to OPTIONAL).
I'm out of options... these were my thouoghts.
a. Why would a certificate not be "valid", if we already have a connection running in the other direction using SSL? My understanding is, that for message channels, both server and client authentification are done which means that both the client (running the SDR channel) and the server (running the RCVR channel) will try to validate the peer certificates. We also successfully have used SSLPEER settings on both ends which is more hint into the direction that nothing SHOULD be wrong with the certificates.
b. we have (since we migrated to MQ7 on the linux qmgr, which is our gateway and also hosts a larger number (~15) SSL channels, disabled the OCSPCheckExtensions, so no OCSP issue here either. We also do not check against any CRL.
Maybe I'm msising soemthing strange here... this is not the first channel I have setup using SSL....
Any lead or input much appreciated :)
Thanks,
Felix |
|
| Back to top |
|
 |
| flaufer |
| Posted: Fri Sep 30, 2011 12:01 am Post subject: Re: SSL working one way, not the other... |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| flaufer wrote: |
Folks,
Im at the end of my (prossibly restricted) wisdome here...
Setup:
Two queuemanagers. One Windows, One Linux.
Two Pair of channels (SDR-RCVR). working fine without SSL.
creating queue manager certificates (witht he proper label). have them signed by their respective CAs (different CAs for each site because different companies) and imported them into the QMGR keystores.
import both of the root CA certificate in both queuemanagers (on our side because we have our own qmgr certificate signed by it, on the peer side to allow the peer to check our certificate which MQ will send during SSL initialization and vice versa).
Now the funny thing.
SDR(Linux) to RCVR(Windows) is working fine. Including SSLPEER setting. CIPHERSPECs have been defined identical. Channel starts. fine.
SDR(Windows) to RCVR(Linux) will not come up. SSLPEER left empty as long as we haven't made it work. CIPHERSPEC identical (check multiple times). SDR goes into retrying and on both ends, we receive AMQ9633.
SSLCAUTH setting does not change the situation (was REQUIRED, changed to OPTIONAL).
I'm out of options... these were my thouoghts.
a. Why would a certificate not be "valid", if we already have a connection running in the other direction using SSL? My understanding is, that for message channels, both server and client authentification are done which means that both the client (running the SDR channel) and the server (running the RCVR channel) will try to validate the peer certificates. We also successfully have used SSLPEER settings on both ends which is more hint into the direction that nothing SHOULD be wrong with the certificates.
b. we have (since we migrated to MQ7 on the linux qmgr, which is our gateway and also hosts a larger number (~15) SSL channels, disabled the OCSPCheckExtensions, so no OCSP issue here either. We also do not check against any CRL.
Maybe I'm msising soemthing strange here... this is not the first channel I have setup using SSL....
Any lead or input much appreciated :)
Thanks,
Felix |
Alright.... I need to admit that, after restarting the Qmgr on the Linux side (our receiver), the channel came up fine... (still SSLCAUTH optional and no SSLPEER, but CHSTATUS shows short peer name and signer certificate on our side)... but I just don't understand it. |
|
| Back to top |
|
|
| flaufer |
| Posted: Fri Sep 30, 2011 1:35 am Post subject: Re: SSL working one way, not the other... |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| flaufer wrote: |
Alright.... I need to admit that, after restarting the Qmgr on the Linux side (our receiver), the channel came up fine... (still SSLCAUTH optional and no SSLPEER, but CHSTATUS shows short peer name and signer certificate on our side)... but I just don't understand it. |
Again me... just setup the same thing in our production environment with the same effect... same error.
Linux (7.0.1.5) to Win (7.0.1.3) working fine.
Win (7.0.1.3) to Linux (7.0.1.5) retrying and we will have to find an outage window to restart the QM...
Very peculiar.
Felix |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 30, 2011 1:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| refresh security type(SSL)? |
|
| Back to top |
|
|
| flaufer |
| Posted: Fri Sep 30, 2011 2:31 am Post subject: refresh security didn't help |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
Jeff,
| mqjeff wrote: |
| refresh security type(SSL)? |
We did it and it did not help.
Also it is unclear to me, how this could have help since the channel in the one direction was already running (and also should have seen - or not seen - the certificates the same way).
Felix
P.S. some colleagues mentioned that this was a known workaround around here for SSL... for exactly these situations... couldn't believe it until I had the same experience. But I want to understand what went wrong because imho a QMGR restart is something I wouldn't want just for putting SSL on a channel. |
|
| 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
|
|
|
|
