| Author |
Message
|
| mca |
 Posted: Mon Nov 28, 2016 11:18 am Post subject: IIB ssl issue |
 |
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
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 |
|
 |
| mqjeff |
| Posted: Mon Nov 28, 2016 11:37 am Post subject: |
|
|
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 |
|
|
| mca |
| Posted: Tue Nov 29, 2016 8:09 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
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 |
|
|
| fjb_saper |
| Posted: Tue Nov 29, 2016 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| mca |
| Posted: Tue Nov 29, 2016 9:13 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
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 |
|
|
| mqjeff |
| Posted: Tue Nov 29, 2016 9:30 am Post subject: |
|
|
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 |
|
|
| fjb_saper |
| Posted: Tue Nov 29, 2016 11:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| nukalas2010 |
| Posted: Sat Dec 03, 2016 10:47 pm Post subject: |
|
|
Master
Joined: 04 Oct 2010
Posts: 220
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 |
|
|
| joebuckeye |
| Posted: Mon Dec 05, 2016 6:27 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
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 |
|
|
| zpat |
| Posted: Mon Dec 05, 2016 7:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| fjb_saper |
| Posted: Mon Dec 05, 2016 8:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| joebuckeye |
| Posted: Mon Dec 05, 2016 9:37 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
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 |
|
|
| fjb_saper |
| Posted: Mon Dec 05, 2016 9:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
|
|
