| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| [Help] Where can I find official statements that SSL renewal |
« View previous topic :: View next topic » |
| Author |
Message
|
| zhanghz |
 Posted: Fri Jul 31, 2009 12:27 am Post subject: [Help] Where can I find official statements that SSL renewal |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Help! Where can I find official statements that SSL renewal will not affect applications?
Our z/OS QMGRs' SSL certs are going to expire. We proposed a procedure to renew the certs, but we were questioned whether we could ensure applications would not be affected after MQ SSL certs renewal. Though we answered "it will not affect applications" during the meeting, the customers wanted kind of official statement/document on that due to some incidents they encountered from some other changes. They insisted to ask applications to test for MQ SSL renewal if we can't provide such proof. (Asking applications to be testing will be a headache in terms of cost, coordination and schedule.)
I looked through IBM MQ security manual and MQ SSL redbook, but coudn't find anything that mentions MQ SSL renewal will not affect the data going through the channel.
Can anyone point me to a referecne?
Thanks. |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Jul 31, 2009 12:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
SSL provides encryption and/or authentication of the MQ channel.
The message data is unchanged when presented by MQ to the application.
Renewing certificates is just an infrastructure change, if SSL did not alter application data before, it won't after.
It's not about renewal.
It's about whether SSL channnels impact application data. The fact you are using them successfully now proves not. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Fri Jul 31, 2009 1:10 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
yes, i understand. I am vexed how we present to the customers and convince them...  |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jul 31, 2009 1:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If they won't believe you - run a verification test before and after and compare the output.
Use IH03 or MO71 to load a file of messages to a queue - send it over the channel and re-save to a file.
Then use a file comparison tool like Examdiff to ensure they are 100% identical. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 31, 2009 5:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
To validate (for the non-believers) that the message data was actually SSL encrypted between the two channel ends, use a packet sniffer during the demonstration.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Jul 31, 2009 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| yes, i understand. I am vexed how we present to the customers and convince them... |
Ask them how they convince themselves that software or hardware upgrades don't affect applications. Apply these methods, as these too are infrastructure changes.
Or, and this is a personal choice, write "it will work" on the side of a trout and hit them. 
Or, again personal, point out to your customers that they're paying a large amount of money for your assistance. Ask if they also get their plumber to convince them the pipe won't leak after their bathroom's been fixed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 31, 2009 8:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I will take a slightly different view of the management demand that you/we prove that something works - or not. I believe this is a valid request. (waiting for the cries of foul to subside...)
Management and end-users are part of the application deployment process (whether they like it or not). I've found it more productive to engage them all. It's one of those professional thingies.
App developers must demonstrate that 2+2=4 point something (never good at math). Application developers and data owners need to create benchmarks (small apps, big apps, d/b apps, transactions, ...) to prove that app changes still produce acceptable results.
O/s support folks should participate in the process of running the benchmarks after substantial (whatever this means) environment changes. WMQ support folks should do the same.
It's a simple task to demonstrate that SSL does its thing. Turn it on, capture msg flows, show the encrpyted flows to auditors and management.
If management doesn't demand proof that it still works, they should be smacked with something trout-like.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Jul 31, 2009 8:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| It's a simple task to demonstrate that SSL does its thing. Turn it on, capture msg flows, show the encrpyted flows to auditors and management. |
And if they demand, before you make any changes, proof positive that the change (when you make it) isn't going to affect the application, this method doesn't help
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 31, 2009 9:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| And if they demand, before you make any changes, proof positive that the change (when you make it) isn't going to affect the application, this method doesn't help. |
I agree. I presumed that a test/demonstration would take place in a test environment, where proof is usually demonstrated. I further presumed (silly me) that there is a percolation process that moves changes from test to qa to production; and that this process is followed religeously.
If management demands a promise (pretty please, cross my heart, hope to die, stick a needle in my eye), I'd list the number of projects I/we have successful delivered.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Jul 31, 2009 9:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I further presumed (silly me) that there is a percolation process that moves changes from test to qa to production; and that this process is followed religeously. |
Certificates are not the same in test or qa as they are in prod. I accept your point that, in theory, you would renew the certs in test and use the same process in prod but some places a) don't use SSL below prod or b) don't believe the process will work in prod without assurances.
| bruce2359 wrote: |
| I'd list the number of projects I/we have successful delivered. |
This is another way of expressing my sentiments about paying money and/or asking the plumber.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 31, 2009 9:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Having pondered this a bit more (during a much-needed shower), I think that this should be one of those "teachable moments" that someone in high-office frequently refers.
In my consulting capacity, I can not promise, guarantee or assure, the quality of the o/s, the WMQ product code, or SSL. This stuff belongs to someone else. I can explain what each offers, and recommend implementation and maintenance policy.
The teachable moment is to explain what Netscape implemented to address the so-called promises of SSL, namely: data integrity (including privacy), non-repudiation, non-impersonation. Of course, we all know that none of these Netscape promises are absolute.
Further, in the same teachable moment, the subject of what else must be secured for SSL to have any meaning whatsoever. Again, see other posts.
Yes, certs are different in test than prod; but it's the app design and change process (including cert management) that assures app integrity - not me promising that everything is going to be OK.
Yes, I've worked for managers that demanded a promise from me. I refer them to the contract we both signed that omits such verbs. IT projects meet, or fail to meet, comittments layed out in the project description and plan. We demonstate that we meet these comittments by running applications and measuring the results - not promises.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
