| Author |
Message
|
| PC_Middleware_1 |
 Posted: Tue Jun 21, 2011 2:22 am Post subject: SSL Certificate Serial Number |
 |
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
| How can you identify the SSL Certificate Serial Number on a (sender) channel? On default the channelstatus gives you information off SSL Peer Name (equals Certificate Subject) and eventualy SSL Issers Name (equals Certificate Issuer). What I'm looking for is the Certificate Serial Number which gives us the oppertunity to check our Certificate database that shows us the expirary date etc. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Jun 21, 2011 2:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why not just interrogate the key store containing the certificate?
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 3:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Why not just use a certificate revocation list? |
|
| Back to top |
|
|
| PC_Middleware_1 |
| Posted: Tue Jun 21, 2011 4:24 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
Because in the keystore the current certificate is placed. However in the security cache an old e.g. expired certificate might be still active, as we unfortunatly experienced as a result on an "frozen" security refresh type SSL.
In order we executed:
Replaced the certificate;
Refresh security type SSL. This command timed out ultimately;
Stopped/started the channels.
It seemed that as a result on starting the channels the new public key was exchanged, however we were still (unnoticed  ) working with the old public key. So, that's why I would like to see/check the Certificate Serial Number as a "parameter" in the channel status so I can identify the usage of the new certificate.
Using a CRL wouldn't solve it either because it "just" revokes the old certificate and doesn't activate the new one. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 4:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PC_Middleware_1 wrote: |
| Using a CRL wouldn't solve it either because it "just" revokes the old certificate and doesn't activate the new one. |
It allows a given MQ channel to reject the old one.
It's not clear what you mean by "activate the new one". Certs are valid on the date they are marked as being valid from and invalid after their expiration date. A cert is 'active' in MQ when it is placed into a given keystore, and inactive otherwise.
So the only control a channel has over whether a certificate is 'active' or not is to either accept it or reject it. And a CRL is a good way to ensure that it stops accepting 'old' but still 'active' certificates.
Or are you looking for advanced keystore management from a central location?
Last edited by mqjeff on Tue Jun 21, 2011 4:31 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 21, 2011 4:30 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PC_Middleware_1 wrote: |
| Refresh security type SSL. This command timed out ultimately; |
Which suggests the command never actually executed. Stop/starting the channels does pretty much the same as the security refresh unless you changed the key store used.
And so what that "...in the keystore the current certificate is placed..."?
_________________
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 |
|
|
| PC_Middleware_1 |
| Posted: Tue Jun 21, 2011 5:04 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
MQJEFF wrote
| Quote: |
| A cert is 'active' in MQ when it is placed into a given keystore, and inactive otherwise. |
I think I must disagree on that. Placing a certificate into the keystore doesn't automaticly activates the cert. You'll either have to stop/start the queuemanager or refresh security, depending which MQ-version is active, to activate the new/replaced cert.
EXERK wrote
| Quote: |
| And so what that "...in the keystore the current certificate is placed..."? |
When I check the cert in the keystore, I'll get the information from that particulair cert. Hence the command didn't do what we intended to do, that is
| Quote: |
| IBM You can refresh the copy of the key repository held in memory, without restarting the channel process, by using the MQSC command REFRESH SECURITY TYPE(SSL). This enables you to use an up-to-date version of the SSL key repository when you have added a new certificate, without having to stop the channel process. |
.
In other words, you'll check the data in the keystore and see the information of an inactive certificate, because the memory in key repository is still used as a reply on a request from a sender channel. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 5:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PC_Middleware_1 wrote: |
MQJEFF wrote
| Quote: |
| A cert is 'active' in MQ when it is placed into a given keystore, and inactive otherwise. |
I think I must disagree on that. Placing a certificate into the keystore doesn't automaticly activates the cert. You'll either have to stop/start the queuemanager or refresh security, depending which MQ-version is active, to activate the new/replaced cert. |
Oh, the *queue manager's* cert. not the client certs.
Yes, if you update the keystore while the qmgr is running you need to do something to cause the qmgr to re-read the keystore.
If you somehow expect to change the certificate in use for a given channel without entirely stopping the channel, you are expecting magic and MQ is not magic.
As exerk said, if the refresh security command timed out, it's because it didn't complete successfully. It's possible that it didn't complete successfully because your channels were still running and didn't have discint's or other values that allowed them to gracefully restart. |
|
| Back to top |
|
|
| PC_Middleware_1 |
| Posted: Tue Jun 21, 2011 5:21 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
Yes, and that's exactly what happened. We neither believe in magic, that's why we want to check it  .
Since it was our first negative expirience with an all in all failed security refresh, we hoped that there would be a command, either runmqsc or internaly, or a parameter for that extra check, to be absolutely sure that the new queuemanagers certificate is active. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 5:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PC_Middleware_1 wrote: |
Yes, and that's exactly what happened. We neither believe in magic, that's why we want to check it .
Since it was our first negative expirience with an all in all failed security refresh, we hoped that there would be a command, either runmqsc or internaly, or a parameter for that extra check, to be absolutely sure that the new queuemanagers certificate is active. |
endmqm; strmqm; |
|
| Back to top |
|
|
| PC_Middleware_1 |
| Posted: Wed Jun 22, 2011 3:37 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
EXERK wrote
Do you mean "you can't use refresh security type SSL" and the only way to implement a new queue managers certificate is to stop/start MQ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 22, 2011 3:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PC_Middleware_1 wrote: |
EXERK wrote
Do you mean "you can't use refresh security type SSL" and the only way to implement a new queue managers certificate is to stop/start MQ? |
No.
You said you wanted "to be absolutely sure".
Refresh Security is just fine. It will work, provided it completes successfully. It just may not take effect on channels that are running at the time.
If you want "to be absolutely sure" that *all* channels at a specific point in time are now using the new certificate, you can stop and start the qmgr. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 22, 2011 3:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PC_Middleware_1 wrote: |
EXERK wrote
Do you mean "you can't use refresh security type SSL" and the only way to implement a new queue managers certificate is to stop/start MQ? |
Misquote; that was someone else in regard to endmqm etc. No, I am not saying you can't use it, but as mqjeff has pointed out, if you have a particularly busy queue manager the command may time out. The queue manager has to stop and restart all channels and if it can't do it in time that can be a cause of the time out. Better to stop all channels, try the command, and see what happens. If it still doesn't complete with channels stopped I'd suspect an issue with the queue manager.
_________________
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 |
|
|
| PC_Middleware_1 |
| Posted: Wed Jun 22, 2011 4:09 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2011
Posts: 6
|
| exerk wrote: |
| PC_Middleware_1 wrote: |
EXERK wrote
Do you mean "you can't use refresh security type SSL" and the only way to implement a new queue managers certificate is to stop/start MQ? |
Misquote; that was someone else in regard to endmqm etc. No, I am not saying you can't use it, but as mqjeff has pointed out, if you have a particularly busy queue manager the command may time out. The queue manager has to stop and restart all channels and if it can't do it in time that can be a cause of the time out. Better to stop all channels, try the command, and see what happens. If it still doesn't complete with channels stopped I'd suspect an issue with the queue manager. |
Thanx for the reply Exerk. Now you can see why you're the Jedi Knight and I'm the Newbie on this forum.
Next week we'll get the opportunity to do it all over again and take the lessons learnt in practice. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 23, 2011 4:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc12740_.htm
| Quote: |
When you issue the REFRESH SECURITY TYPE(SSL) MQSC command, all running SSL channels are stopped and restarted. Sometimes SSL channels can take a long time to shut down and this means that the refresh operation takes some time to complete. There is a time limit of 10 minutes for an SSL refresh to complete (or 1 minute on z/OS®), so it can potentially take 10 minutes for the command to finish. This can give the appearance that the refresh operation has "frozen". The refresh operation will fail with an MQSC error message of AMQ9710 or PCF error MQRCCF_COMMAND_FAILED if the timeout is exceeded before all channels have stopped. This is likely to happen if the following conditions are true:
The queue manager has many SSL channels running simultaneously when the refresh command is invoked
The channels are handling large numbers of messages
If a refresh fails under these conditions, retry the command later when the queue manager is less busy. In the case where many channels are running, you can choose to stop some of the channels manually before invoking the REFRESH command.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
