| Author |
Message
|
| PeterPotkay |
 Posted: Tue Sep 08, 2009 10:02 am Post subject: Anything like SSLPEER in WMB? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm looking at the various things we can set related to SSL at the Broker Level or the Execution Group level. While we do have the ability to require the incoming SSL Client to present a cert (clientAuth = true), I don't see anyway to filter on the SSL Client's cert. For example:
DEV
SSLClient1 talks to WMB1
QA
SSLClient2 talks to WMB2
PROD
SSLClient3 talks to WMB3
The SSL Client got Verisign certs for all 3 of its certs. All are signed by the same CA cert. All 3 have unique Distinguished Names. But how do I tell WMB2 to only accept the Verisign cert from SSLClient2? If SSLCient 1 or 3 tries to talk to WMB2, it will be allowed because WMB2 will accept the valid Verisign certs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Nov 13, 2013 10:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Me again.
I don’t see any way to filter the incoming certs like I can with SSLPEER in MQ.
Is there a solution in WMB 8 for this? I first ran into this at 6.1 and unless I’m searching incorrectly in the InfoCenter, this appears to still be a gap.
Creating an execution group for each individual message flow, creating a dedicated trust store per execution group, using a self signed cert per client and purging the trust store of all signer certs other than the one specific self signed one for that flow / execution group is one way I suppose, but obviously doesn’t scale.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 13, 2013 10:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can do a lot of sophisticated things with Identity that's part of the actual message structure.
But whether or not certificate information is part of the actual message structure is dependent entirely on the transport in use - a raw TCP/IP message for example is almost certainly not going to carry it.
It sounds like you want to configure an SSL proxy of some kind - perhaps a datapower box. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Wed Nov 13, 2013 10:38 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| Why not use something like IHS to proxy (and load balance) such requests? You can setup a trusted connection between IHS and the EG(s). |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 13, 2013 10:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Putting something in the middle, like DataPower, doesn't really help.
DEV
DataPowerDEVSSLClient1 talks to WMB1
QA
DataPowerQASSLClient2 talks to WMB2
PROD
DataPowerPRODSSLClient3 talks to WMB3
Same problem.
If WMB3 trusts DataPowerPRODSSLClient3 because it has a valid Verisign ticket, WMB3 has to trust every client with a valid Verisign cert.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sridhsri |
| Posted: Wed Nov 13, 2013 11:07 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
If you use DataPower, you can create a AAA policy in the web service proxy to add DN filtering. You can even maintain a "file" that contains a list of "allowed DNs" and have the WSP only allow those DNs access the backend.
ps: It doesn't have to be DataPower. You can do it using IHS also. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 13, 2013 1:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
But that doesn't address the problem that the WMB server will still accpet an SSL connection from *any* SSL Client presenting *any* SSL certificate that is valid for the signer certs that are in the WMB trust store.
If you purge the WMB trust store to only leave the one root CA cert (and its intermediates) for the legitimate SSL Client you have, that still allows other unintended clients with certs signed by that particular CA to connect.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 13, 2013 1:46 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
you should be able to filter backend connections in DP using a policy based on DN.
i.e. This DN can go here, but not here. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 13, 2013 1:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What if we purge the WMB trusstore of all certificates leaving it empty. Then only load in the public half of the intended's SSL Client certificate.
Would that only allow the intended SSl Client to connect, but other clients with valid SSL certs from that common CA would not be allowed?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sridhsri |
| Posted: Wed Nov 13, 2013 2:00 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| I see the problem. You are right - i don't think there is a way to do this. You've already suggested using self-signed certs. That might be the only way. But you don't have to proliferate self-signed certs. A single cert can be used to establish trust between DataPower and WMB. The rest of them follow the path suggested above (using AAA policies on DP). |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Nov 13, 2013 2:18 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
I believe in IIB V9 client certs are "unpacked" into the LE from where you could process them to do what you want...
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 13, 2013 3:40 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I wrote this up to walk thru the scenarios in my head. Comments?
Assume all SSL Servers and SSL Clients are internal application servers and internal WMB servers.
Since WMB does not support filtering by the Distinguished Name (DN) of a certificate, or use Certificate Revocation lists (CRLs), technically anyone with a valid cert signed by any of the public CAs will be able to “authenticate” themselves.
However, if we use self signed certificates on the WMB server only the legitimate partner will have a copy of our self signed certificate’s public key and so only the legitimate partner will be able to make the initial handshake. In other words, when they present their certificate to us, we will likely authenticate it no matter what, since we have all the default signer certs and WMB does not offer any DN filtering. But when we send them our self signed cert for the other half of the SSL handshake, the connection will fail since they don't have our public self signed cert - only legitimate SSL Clients (i.e our DataPower appliances) have our self signed public key and so the connection will only work with them. Another SSL Client, even if they present a valid SSL certificate, will fail the 2nd half of the full SSL handshake and thus a successful connection is avoided. Can we leave all the public default certificates in the trust store in this scenario - no harm?
Maybe not. When the WMB server sends the public part of the self signed certificate to the unintended SSL client it is true it will be rejected initially. But what’s to stop that client from saving that public self signed WMB cert (use your FireFox browser!), storing it in its trust store, and trying again?
Perhaps the only way around this is to start with an empty trust store and then only load in the public half of the legitimate SSL Client’s certificate. That way the initial SSL handshake only succeeds if the specific, intended certificate is presented by the client (as validated against the public half of its cert already manually added to the trust store), and its safe for WMB to present back its public cert back to the SSL client, completing the hand shake. If an unintended SSL Client present a valid public cert, even from the same CA as the intended SSL Client, the initial handshake will fail due to the absence of the signer root/intermediate certs as well as the absence of that particular client’s public cert in that trust store.
If both the SSL Client and WMB (as the SSL Server) are using publicly signed certs the lack of DN filtering and CRLs is a much easier scenario to take advantage of. It’s likely the 2 way SSL handshake will succeed on the first try since both sides likely have all public root signer certificates. However can the same method be used? Start with empty trust store and manually populate it with the public half of intended SSL Client cert?
What about when the same Execution Group needs to act the role of SSL Client, calling out to another app that acts the role of SSL Server? Since an Execution Group can only have one trust store, it will then need to authenticate the SSL Server using the same truststore. If the one trust store was emptied per the above to support WMB as an SSL Server, it means all the general signer certs are not there. We would need the SSL Server app to provide us their specific public half because we won’t and don’t want to have the root/intermediate CA certs. If they won’t play ball, saying we should just use the root CAs, we can use the Firefox trick to grab their public half of the cert, load it and try again, right? If this works this way, the truststore only ends up with specific public halves of specific SSL certs we want to connect with, while all other SSL connections, even ones using legitimate valid SSL certs, get rejected?
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Thu Nov 14, 2013 5:40 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 13, 2013 8:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
What if we purge the WMB trusstore of all certificates leaving it empty. Then only load in the public half of the intended's SSL Client certificate.
Would that only allow the intended SSl Client to connect, but other clients with valid SSL certs from that common CA would not be allowed? |
You need to set up a policy with 2 way SSL. I.e. you need the cert from the client in your truststore...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 14, 2013 4:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| PeterPotkay wrote: |
What if we purge the WMB trusstore of all certificates leaving it empty. Then only load in the public half of the intended's SSL Client certificate.
Would that only allow the intended SSl Client to connect, but other clients with valid SSL certs from that common CA would not be allowed? |
You need to set up a policy with 2 way SSL. I.e. you need the cert from the client in your truststore...
Have fun |
Isn't that what I wrote?
(I'm not being a wise-arse, I'm really asking  )
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 16, 2013 2:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
| PeterPotkay wrote: |
What if we purge the WMB trusstore of all certificates leaving it empty. Then only load in the public half of the intended's SSL Client certificate.
Would that only allow the intended SSl Client to connect, but other clients with valid SSL certs from that common CA would not be allowed? |
You need to set up a policy with 2 way SSL. I.e. you need the cert from the client in your truststore...
Have fun |
Isn't that what I wrote?
(I'm not being a wise-arse, I'm really asking ) |
Not quite. Your 2 way SSL handshake supposes only the public root signer cert are part of the truststore. That does not constitute a 2 way SSL handshake for the broker.
For the broker the 2 way SSL with the right policy set will also confirm that the client is who he says he is and will need the client's public cert in the truststore in order to do that.
This means that the policy is checking whether the client cert presented on the wire matches the one in the truststore. (Where of course you need the full cert chain for the client cert)
A lot more complex than the MQ 2 way SSL where that verification is done through the SSL PEER information.
Some people like to force access through DP, or their equivalent edge device, because of this; accepting only the DP's cert. (less maintenance on the broker truststore)....
Have fun.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
