WebSphere webservice call using SSL ServerTrustFile.jks

Hey HG

We actually have a VeriSign cert our Systems group loaded into our DummyServerTrustFile (I know I know, not my choice to use this - lack of standards in this area) and our java/jre/lib/security/cacerts file.

We kept getting SSLHandShakeFailed: expired cert.

After going round and round and doing some research this is where we've come:

1) Updating webservicesclient.xml (& associated ibm-webserviceclient-bnd/ext files ) via IBM-RAD security extensions / port bindings tab.)  
>I kept getting mixed results.(variety of SSLHandShake exceptions (key not found / expired cert)

2) Testing a local standalone webservice client (using IBM's handy test JSP testClient.jsp) with no changes to webserviceclient AND a new CERT file in root C:\  
> I am now getting a WebServiceTimeout.
   (This tells me I am hitting the WS service
     and causing it to think at least - no exception.)

3) I read on some tech forum to remove expired certs (point #2's test)

4) I asked our Systems group to remove expired certs from both Server Trust AND cacerts.
   > and we are going to try to WS call as-is (no other configuration changes - This test is pending.)


QUESTION:
Do you have any suggestions to follow or things to consider as we try to conquer this SSL handshake error?

Thanks
- - - - - - -
John 14:6

One more thing came my way I forgot to mention above: if the certs are not in sync between client and server, the server will timeout, an error I am experiencing above.  True?  

Does the One Level VeriSign cert provide the needed public / private keys for both sides?
Is there a separate private key we need to have installed?

I am separate from that process.  I just program :)

Yo HonorGod -

The Cert issue makes sense but I need clarification:
- so would this mean per server only one Level 2 and one level 3 cert is valid at a time?
- We cannot install multiple trust certs for multiple reasons (multiple servers)?

I'm still getting my arms about how J2EE servers handle security certs so please pardon my ignorance, and thank you so much for taking the time to answer these questions.

no, it means that should verify which you have marked as "default"  ;-)

and don't worry about lack of knowledge... we were all there at one time or another...

Yo HG

So my internal SysEng group asked:
-> Did the expert say how you know the cert is default?

They also stated:
-> Note that this keystore is _shared_ so changing the default may not be advised.

Is setting a key as default a good practice or is this a work-around?

Thanks

Well, what tool are you using to view / manipulate the certificates?

The iKeyman utility will have an asterisk '*' beside the default cert.

If none is selected as the default, then the valid certificate with the earliest expiration may be chosen / picked as certificate to be used.

So,

- Does iKeyman show any certificate as the default?
- What expiration dates do the certificates have?

Q: Is setting a key as default a good practice
A; Yes.

I have invited my SysEng group guys to come join us in this conversation through EE.

I am at the point where this appears to be a server side issue.
The Web Service was working before the Cert was applied to the provider and the client.

Does this make sense?

Yes, sort of.

So, what certificates are we talking about?

- Ones in the web server, or

- Ones in the Application Server?

It sounds like we have an F5 Load Balancer managing the SSL for us.

The steps I've taken:

1) Firefox Browse to the WS URL:  "And now . . . some services" displays

2) Using Firefox - export the Certificate to a local file

3) Create a new TRUST Keystore using iKeyMan.  C:\webickeystore.jks

4) Import the exported cert file (Step 2) into the new KeyStore

5) Ensure WAS 5.1.2 sees STEP 3 keystore as the Trust file

6) Exec local Web Service Gen test client  (TestClient.jsp)

7) The process times out.

Do I need to update the webservicesclient.xml ?

Thanks

At this point my SysEng group is going to open a ticket with IBM.
We got the same error on WAS 6.0 and we've done everything we can think from a client stand point.

I am suspicious the load balancer is not updated properly with the right certificate.

Thanks for the attempt to help with this frustrating problem.

This problem appears to extend beyond the scope of this question.  I am awarding points for some excellent information provided for SSL/JKS processing in a WAS environment.