cacerts vs. jks in a cxf-based client

Question

I am trying to configure my cxf-based client to communicate with a web service I have written (also cxf-based).

The web service itself works flawlessly, tested via soapUI.

The client, however, builds fine but upon invocation throws a SunCertPathBuilderException.

Suspecting this has to do with providing a valid path to a trustore that contains the server's cert, with a valid certificate chain to a trusted cert, I first tried to export that server's certificate to a PFX so that I can import it to the project's own .jks. That turned out to be impossible because it requires a private key which the exporting utility (certmgr.msc) greys out for some reason.

So I tried to tackle the problem from a different direction: I know that soapUI has no problem communicating with the web service over SSL, and I didn't install any certificate for it, so it must be satisfied with a root certificate (CA) already present in its cacerts file.

But... the http:conduit section my CXF-based application context .xml requires a JKS type keystore... so it looks like I am in a catch 22 situation.

Unless a cacerts file is of JKS type?

If not, is there a way to convert or export a certificate from a cacerts to a .jks?

What is the right way of solving this?

Answer 1

To find the type of the cacerts file, just use keytool:

~> keytool -list -keystore cacerts
Enter keystore password:

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 77 entries

So the answers are:

1. Yes, cacerts is of JKS type.

2. There is no need to convert cacerts to JKS because it is already in that format.

3. One approach to solving this is to find the server.xml file in Tomca'ts conf directory (in the client's server), then find out how the certificates or trust store are specified in the <Connector element, then...

If something new needs to be added to the client's trust store, find the original .crt and key files that were used to install the certificates on the client's server.

Otherwise, just make the client's application context XML point to the same trust store used by soapUI (as it has been proven working).