ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker SupportIIB ssl issue

Post new topicReply to topic
IIB ssl issue View previous topic :: View next topic
Author Message
mca
PostPosted: Mon Nov 28, 2016 11:18 am Post subject: IIB ssl issue Reply with quote

Disciple

Joined: 09 Mar 2005
Posts: 181

We are using IIB v10 and here is the architecture

Datapower (front end) -> IIB (Middleware) -> Windows backend application.

We have SSL between Datapower and IIB since many years on existing projects. For that i (Middleware) created a keystore and Truststore on Linux where IIB is installed and added to IIB, cretated a certificate in keystore, extracted it and added it to my truststore and also gave it to Datapower admin for SSL handshake.

Now, we got a new backend application which uses SSL. They gave their certificate to me (IIB). I added it to our keystore and Truststore, backend connectivity works fine, but Datapower to IIB stops working. If i add the certificate to my Truststore only, Datapower to IIB works fine, but IIB to backend doesnot work.

Can some one tell me what i might be missing here to fix both front and backend.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
mqjeff
PostPosted: Mon Nov 28, 2016 11:37 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The keystore contains the key that identifies who you are.

The truststore contains certificates in the CA chain that identify who you trust.

The only key in the keystore should be the one created for IIB.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
mca
PostPosted: Tue Nov 29, 2016 8:09 am Post subject: Reply with quote

Disciple

Joined: 09 Mar 2005
Posts: 181

I made changes and I have my Middleware Linux IIB certificate in my keystore that frontend IIB is successfully consuming. I placed the backend Windows certificate in my Truststore, but getting 403-Forbidden error when trying to consume their webservice.

My keystore is only haveving my certificate and truststore is only having the backend presented certificate. What else might i missing here?
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
fjb_saper
PostPosted: Tue Nov 29, 2016 8:55 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19923
Location: LI,NY

First you need to be crystal clear.

a) we are talking about an outbound call
b) you need the call to be SSL (TLS)
b1) SSL one way
b2) SSL two way

b1 you only need a truststore and it needs to contain the target's certificate chain.

b2) You need a keysstore adn a truststore. The truststore needs to contain the tartget's certificate chain and your private key's signer cert chain.
The private key will have to be something that the target accepts. This is one of the cases where you may have more than one key in the keystore. Obviously the default key would be that of the IIB server, however you may need to use a specific key that is accepted by the target. This specific key should be in your keystore and needs to be labelled. You can then identify by its label when needing to make the call to the target.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mca
PostPosted: Tue Nov 29, 2016 9:13 am Post subject: Reply with quote

Disciple

Joined: 09 Mar 2005
Posts: 181

Here is my infrastructure.

Frontend Datapower -> IIB (One-way SSL. Keys generated on IIB and stored in IIB keystore and gave a copy to Datapower for handshake)

Working fine...


IIB -> Backend Windows application (One-way SSL. Keys generated on backend Windows and gave a copy to IIB which is stored on IIB Truststore for handshake).

403-forbidden (not working)...
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
mqjeff
PostPosted: Tue Nov 29, 2016 9:30 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

SSL is a client/server protocol.

For one way SSL, the client does not send any certs. The server responds with it's public cert. The client examines the CA chain in that public cert and compares them to what's in it's trust store. If there's a match, then the client trusts the server.

For two way SSL, the first step is the same as one-way SSL. The client decides if it trusts the server. The client then sends it's public key to the server, and the server compares the CA signer chain with it's trust store.

In your case, you need to determine whether you are using one way or two way SSL and which places IIB is acting as a server and which places it's acting as a client.

The keystore holds the key that identifies IIB.

The truststore holds the CA signer keys that IIB trusts.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Nov 29, 2016 11:33 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19923
Location: LI,NY

Note the truststore needs more than just the CA signer keys that IIB trusts.
It needs the CA signer chains. That means all the intermediate certs between (and including) the signer cert and the CA root need to be in the truststore...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
nukalas2010
PostPosted: Sat Dec 03, 2016 10:47 pm Post subject: Reply with quote

Master

Joined: 04 Oct 2010
Posts: 217
Location: Somewhere in the World....

mqjeff wrote:
SSL is a client/server protocol.

For one way SSL, the client does not send any certs. The server responds with it's public cert. The client examines the CA chain in that public cert and compares them to what's in it's trust store. If there's a match, then the client trusts the server.

For two way SSL, the first step is the same as one-way SSL. The client decides if it trusts the server. The client then sends it's public key to the server, and the server compares the CA signer chain with it's trust store.


No body can explain better than this..
Back to top
View user's profile Send private message
joebuckeye
PostPosted: Mon Dec 05, 2016 6:27 am Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 343
Location: Columbus, OH

fjb_saper wrote:
Note the truststore needs more than just the CA signer keys that IIB trusts.
It needs the CA signer chains. That means all the intermediate certs between (and including) the signer cert and the CA root need to be in the truststore...


I don't believe this is quite correct. Your truststore should only contain the CA root certs. The intermediate certs need to be returned by the endpoint you are connecting to (as well as the cert the endpoint itself is using).

Your truststore should be changing only when you need to connect to a new endpoint that has a cert chain initiated by a new CA root that is not already in your truststore.
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Dec 05, 2016 7:37 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5669
Location: UK

The truststore needs to be able to validate the application cert and therefore must contain all the CA certs needed to do so.

I have never heard of an endpoint supplying its own intermediate signer certs during the validation - that would defeat the point of the validation in that the validator determines the CA signer certs to be used.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Dec 05, 2016 8:25 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19923
Location: LI,NY

joebuckeye wrote:
Your truststore should only contain the CA root certs. The intermediate certs need to be returned by the endpoint you are connecting to (as well as the cert the endpoint itself is using).

Your truststore should be changing only when you need to connect to a new endpoint that has a cert chain initiated by a new CA root that is not already in your truststore.


Have you tried it? What happened when you tried it?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
joebuckeye
PostPosted: Mon Dec 05, 2016 9:37 am Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 343
Location: Columbus, OH

Yes, we only install root CA's in our trust stores. Endpoints need to return their own cert and all intermediate certs when you call them. If the endpoint does not do this they will probably cause the certificate chain to be broken and the endpoint will not be trusted.

Web browsers only have root CA's in their truststores. Why shouldn't any other application calling an endpoint do the same?

We didn't really follow this convention until we got Datapower and during our endpoint configuration realized we should be providing the intermediate certs also.

This has resulted in us having much simpler truststores and lower maintenance issues because root CA certs have long expiration times.

It comes down to the server (not the client) being responsible for establishing the certificate chain to a well known root CA so it should be returning the endpoint cert and all intermediate certs.

Here is a link that explains this pretty well: https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Dec 05, 2016 9:57 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19923
Location: LI,NY

joebuckeye wrote:
Yes, we only install root CA's in our trust stores. Endpoints need to return their own cert and all intermediate certs when you call them. If the endpoint does not do this they will probably cause the certificate chain to be broken and the endpoint will not be trusted.

Web browsers only have root CA's in their truststores. Why shouldn't any other application calling an endpoint do the same?

We didn't really follow this convention until we got Datapower and during our endpoint configuration realized we should be providing the intermediate certs also.

This has resulted in us having much simpler truststores and lower maintenance issues because root CA certs have long expiration times.

It comes down to the server (not the client) being responsible for establishing the certificate chain to a well known root CA so it should be returning the endpoint cert and all intermediate certs.

Here is a link that explains this pretty well: https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/

NOTE: This would be valid only for one way SSL and the truststore holder acting as a client.
If you're acting as server you are required to have the full cert chain as you need to provide it to the caller.
If you are running 2 way SSL you still need to have to full cert chain related to your own certificate in the truststore...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportIIB ssl issue
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.