| Author |
Message
|
| MattyMQ |
 Posted: Tue May 08, 2012 4:32 pm Post subject: Client connections and SSL chain |
 |
|
Newbie
Joined: 08 May 2012
Posts: 3
|
| I need a way to detemine the entire SSL certificate chain on incoming SSL enabled svrconn channels.. The SSLCERTI field provides a layer, but not all of it. IBM saying write your own channel exit or submit and enhancement. Has anyone had to do the same? Suggestions? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue May 08, 2012 8:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
moved to security.
Can you be a little bit more specific? Normally you would make sure that all trusted certs and intermediate certs are already in your truststore....
What is not happening for you there?
Are you saying that at time of connection you need to verify every single cert in the trust chain, and I mean here in detail in your program/exit, not as in checked by the SSL framework and this is sufficient.... ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| MattyMQ |
| Posted: Wed May 09, 2012 5:26 am Post subject: SSL cert chain identification |
|
|
Newbie
Joined: 08 May 2012
Posts: 3
|
| A different team manages 200 XI50's with the WMQ embedded client code and does their own cert management. My team cannot log on to look at their certificates and we had a massive problem when one of the intermediate root signers expired. My team let it go out of service thinking that no one in our environment was using the ICA cert since 2007. Turns out the XI50's were using ICA and not ICCA certs and we had a horrible problem. I am now trying to figure out how we can identify the entire chain when a client completes the SSL handshake and the svrconn goes into a running state. The SSLCERTI parameter on the running svrconn shows part of the chain, but I need the entire chain to see all of the singers and know for sure what is connection. I am lukcy in that I have 1000 mgrs, but only 2 environments that use client. I have counterparts that have 1000's of client connections and fear they may be hit by this same issue when intermediate signers expire. Thx. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 09, 2012 9:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do you really want to chase the cert chains in a SVRCONN security exit - each and every time an app connects?
Perhaps you could do this in a batch script from time-to-time.
_________________
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 |
|
|
| MattyMQ |
| Posted: Wed May 09, 2012 9:39 am Post subject: |
|
|
Newbie
Joined: 08 May 2012
Posts: 3
|
| No, I don't "want to". I have a need to know. This is because the people that manage the Client certs are NOT on my team. Therefore a simple mistake when ordering the cert can lead to a severe problem. I am not as concerned with how to execute, that is for later. Right now I want to know if it is possible or already available. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 09, 2012 9:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There are some open-source tools.
Search google for 'program to display ssl certificate chain'.
Search also for 'ssl tools'.
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed May 09, 2012 8:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| MattyMQ wrote: |
| No, I don't "want to". I have a need to know. This is because the people that manage the Client certs are NOT on my team. Therefore a simple mistake when ordering the cert can lead to a severe problem. I am not as concerned with how to execute, that is for later. Right now I want to know if it is possible or already available. |
You should know or have an inventory of the certs in your different cert stores... Now all you need to do is delete and replace the expired intermediate certs in there. Certs have a valid until date. Your security team can probably also alert you when a cert gets put on the revocation list.
Of course if one of those intermediate certs was used to sign your qmgr's cert you will need a new cert too...
The rest is just maintenance...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| flaufer |
| Posted: Thu Jul 05, 2012 9:49 pm Post subject: but if.... |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| fjb_saper wrote: |
You should know or have an inventory of the certs in your different cert stores... Now all you need to do is delete and replace the expired intermediate certs in there. Certs have a valid until date. Your security team can probably also alert you when a cert gets put on the revocation list.
Of course if one of those intermediate certs was used to sign your qmgr's cert you will need a new cert too...
The rest is just maintenance... :innocent: |
What can be done to validate intermediate certificates that are NOT stored in the local keystore, but are transferred when the connection is established? According to RFC 5246 there is the option to have online the root Certificate available in your own keystore.
Of course, the connection will (and should!) fail with some error message saying "certificate not valid", but troubleshooting this is somewhat difficult.
Felix |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 06, 2012 5:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try open ssl tools in google...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| flaufer |
| Posted: Fri Jul 06, 2012 5:56 am Post subject: *humm* |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| fjb_saper wrote: |
| Try open ssl tools in google... :innocent: |
Ahmm. yes... thanks. :-)
Didn't help me figure out how to analyze SSL certificate chains that come during session startup and are not stored in my keystore.
I have a root certificate in my qmgr and somebody sens his QMGR-certificate along with a certificate from an intermediate CA that signs his QMgr-certificate and is itself signed by my root certificate in my keystore.
1. How do I check these intermediate certificates? In other words... how can I tell WHY my qmgr declined the session?
2. How could I prevent connections with certified qmgr that have certificates issued by a CA I do explicitetely NOT trust, even though the root-CA is in my keychain (and I can't remove this root certificate because I need it to check the trust towards a second intermediate CA).
Felix |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 06, 2012 6:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
CAs are used to verify the identity of the holder of the certificate. You either trust them to do that or you do not trust them. You can't choose to trust them for some identities and not for other identities.
SSLPEER is used to control what identities can establish connections to your queue manager. |
|
| Back to top |
|
|
| flaufer |
| Posted: Fri Jul 06, 2012 6:16 am Post subject: |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| mqjeff wrote: |
CAs are used to verify the identity of the holder of the certificate. You either trust them to do that or you do not trust them. You can't choose to trust them for some identities and not for other identities.
SSLPEER is used to control what identities can establish connections to your queue manager. |
I know... I just have a counterpart that somehow rejects accepting our PKI because we only split intermediate CAs for test and production environments and not for the root CA (one single root-CA signs two intermediate CAs which then each sing the queuemanagers certificates).
SSLPEER would help, but only if the two intermediate CA never certify the same leaf (qmgr-cert), which cannot be prevented.
Felix |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 06, 2012 8:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| flaufer wrote: |
| SSLPEER would help, but only if the two intermediate CA never certify the same leaf (qmgr-cert), which cannot be prevented. |
SSLPEER works exclusively on the distinguished name of the certificate. It has no understanding in any way about the signers of the certificate - except as those have been added to the DN (which shouldn't be...)
The distinguished name of the certificate for a queue manager should uniquely represent the queue manager. You should not have a queue manager that has the same name in both TEST and PRODUCTION. Even if, somehow, you do have two queue managers that have the same name, that does not require in any way that they have the same distinguished name. The Distinguished Name should indicate that one is TEST and the other is PRODUCTION.
You should not have the same queue manager that is connected to BOTH test and PRODUCTION, either.
So I still don't understand the problem you're trying to solve. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 06, 2012 6:21 pm Post subject: Re: *humm* |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| flaufer wrote: |
I have a root certificate in my qmgr and somebody sens his QMGR-certificate along with a certificate from an intermediate CA that signs his QMgr-certificate and is itself signed by my root certificate in my keystore.
1. How do I check these intermediate certificates? In other words... how can I tell WHY my qmgr declined the session?
2. How could I prevent connections with certified qmgr that have certificates issued by a CA I do explicitetely NOT trust, even though the root-CA is in my keychain (and I can't remove this root certificate because I need it to check the trust towards a second intermediate CA).
Felix |
How about using a CRL or certificate revocation list?
Yes you need to make it available (Highly available?) to your qmgrs. But it would solve the problem, don't you think?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 07, 2012 6:29 pm Post subject: Re: SSL cert chain identification |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
As always, I'm a bit confused with pronouns like mine and theirs...
| MattyMQ wrote: |
| A different team manages 200 XI50's with the WMQ embedded client code and does their own cert management. |
Are you saying that you have no authorization whatsoever to the client certificate store?
| MattyMQ wrote: |
| My team cannot log on to look at their certificates and we had a massive problem when one of the intermediate root signers expired. My team let it go out of service thinking that no one in our environment was using the ICA cert since 2007. |
Are you saying that you have no authorization whatsoever to the server certificate store?
_________________
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 |
|
|
|
|
