| Author |
Message
|
| girish_tharwani |
 Posted: Tue Jun 16, 2015 10:11 pm Post subject: Upgrading a cluster from SSL to TLS |
 |
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
Hello,
I am trying to come up with a strategy to migrate a cluster (with many qmgrs) from using SSL to TLS. All qmgrs have been upgraded to a WMQ version that supports TLS but I am struggling with next steps. I can not change cluster senders/receivers on all qmgrs in big-bang manner because I wont get that big an outage windows from business and I am not able to think of a technical way of doing it channel-by-channel or qmgr-by-qmgr. If you can give me any advise about it from your experience or point me to any document published by IBM about migration strategy, I will be very grateful.
Thanks |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Jun 17, 2015 3:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Wed Jun 17, 2015 3:48 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| Thanks Peter. Had quick a peak and it seems very useful. I will read it in detail tonight. Thanks again. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Jun 17, 2015 4:21 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Wed Jun 17, 2015 7:16 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
Thanks tczielke. But I think this approach will require changing all channels in a short period of time. Because once clusrcvrs have been changed and a cluster change happens, clussdrs will go in retry trying to publish that info to FR. The approach suggested in other developerWorks article is lot more comprehensive and allows the changes to be done over a longer duration. Don't need to cram everything in one day.
Last edited by girish_tharwani on Wed Jun 17, 2015 7:30 am; edited 1 time in total |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Jun 17, 2015 7:26 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
That wasn't my experience. When the CLUSRCVR channel was changed from SSL to TLS, it did not break any existing auto defined CLUSSDR channels that were already running. When any new auto defined CLUSSDR channels restarted, they then picked up the new TLS change from the CLUSRCVR channel definition and were able to restart.
If I changed a CLUSRCVR that had a manually defined CLUSSDR channel on the other end, I did make sure to get the manually defined CLUSSDR channel changed shortly after the CLUSRCVR channel was changed.
The SSL to TLS changes for our multiple clustered environment was actually pretty painless. It was the changing the point-to-point channels from SSL to TLS which was the big pain in the rear.
I did all of this over a 7 hour period on a Saturday, and didn't see one report of a channel being in a retrying state. But as with many things, I would recommend validating your approach with IBM, first (instead of following the advice of a stranger on the internet  ).
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Thu Jun 18, 2015 1:22 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| Sorry, I should have been specific in my post. I was refereing to manually defined CLUSSDR and as you mentioned, we will need to update them in minimum time possible to avoid retrying alerts. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 18, 2015 2:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
You may want to create a 2nd channel pair with TLS, get it running, and then decommission the first channel pair. Or, is there a one-channel pair policy at your site?
_________________
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 |
|
|
| KLUSTENATOR |
| Posted: Sun Aug 09, 2015 12:21 pm Post subject: Darn Poodles |
|
|
Newbie
Joined: 31 Oct 2013
Posts: 1
|
Yeah I have to go through this process as well. You're probably doing it because of POODLE right? I already upgraded all the point to point channels between open systems applications and our mainframes (and vice versa). Now comes the clustering...
Still nebulous about whether I should go the slow and steady route (mirror the clusters with the new TLS cipher and then delete the old) or the speedy/risky way (change them all at every end at the same time and pray the cipher picks up everywhere with no retries). I'm thinking it's smarter to go the slow and steady way for this, don't want any rude production outages waking me up... |
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Aug 31, 2015 12:01 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 314
|
IBM
This whole SSL/TLS process needs to be rethought. We have way too many MQ’s inside a single cluster that make this type of administrivia expensive for Admins to swap and too time consuming. And, we have to PAY for certificates and they expire – REALLY? This is the best minds could come up with in Hursley?
We customers need something better than this mess to encrypt data across the wire. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 31, 2015 12:05 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well.
Hursley certainly didn't invent SSL. And the fact that you have to Pay for certificates that then expire isn't really Hursley's fault either.
You can certainly use an internal CA for all your queue managers, and create certificates that basically don't expire.
And Hursley - or anyone else - providing a central repository and distribution method for SSL certs means that they are also providing a single point of access to all of your certificates.
Modifying channels and updating certs should be something that is scripted, like any other admin task. So it shouldn't take more effort for admins than any other basic config task. It may take a longer outage, but that's a separate issue.
This may be more conveniently done by keeping all the certs in one place - but that again has a risk if the certs are kept there long term.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 10, 2015 4:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| cicsprog wrote: |
IBM
This whole SSL/TLS process needs to be rethought. We have way too many MQ’s inside a single cluster that make this type of administrivia expensive for Admins to swap and too time consuming. And, we have to PAY for certificates and they expire – REALLY? This is the best minds could come up with in Hursley?
We customers need something better than this mess to encrypt data across the wire. |
Have you considered using Security Exits? Take a good look at Capitalware's products.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 11, 2015 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| cicsprog wrote: |
| This whole SSL/TLS process needs to be rethought. We have way too many MQ’s inside a single cluster that make this type of administrivia expensive for Admins to swap and too time consuming. And, we have to PAY for certificates and they expire – REALLY? This is the best minds could come up with in Hursley? |
What SSL/TLS process? The way MQ (even inside a cluster) uses SSL/TLS is no better and no worse than the process used for a web service or for a network component like an F5. That's not an abstract statement - we're currently rolling out a network level change to disallow traffic encrypted with anything other than TLS and the amount of MQ channels in retry / inaccessible web service end points is generating a lot of noise. That's separate and distinct from the move from SHA-1 to SHA-256 that's requiring new signer certs in all the trust stores from WAS to IIB via MQ.
As to paying for certificates that expire, if they didn't expire someone who gained fraudulent access to one could use it forever. If the traffic being encrypted isn't valuable enough to warrant a paid certificate, create an internal CA and sign certificates with that. I commend the works of T-Rob to you on this subject.
Also the "administrivia" of supporting your MQ estate is what you're (presumably) paid to do. It's unrealistic to hope that your role will be defining objects, checking logs and looking for the odd lost message.
| cicsprog wrote: |
| We customers need something better than this mess to encrypt data across the wire. |
Let's assume Hursley came up with "something better"; they're clever people. The time you save will be completely swallowed up the next time you face a security audit and you have to explain that the MQ traffic is being encrypted by a proprietary system the auditors have never heard of, proving to them it's as secure as the industry standard PKI that they know and love and in all probability explaining why you're using that instead of the site-wide PKI standard they enforce for the web services on site.
You want something better? Raise an RFE and post the link in this forum. It's why the RFE system was started. Votes get changes but you won't get my vote. I'll stick to getting past my security audit by writing "uses standard SSL from internal CA as per <section n of internal security regulations>" in the response box and signing it.
You come up with some good ideas to improve management and simplify all of this (I offer as an example the ability to use multiple labels in MQv8) and those are RFEs I'll seriously consider voting for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
