4

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?

Community
  • 1
  • 1
Withheld
  • 4,603
  • 10
  • 45
  • 76
  • 1
    Are your client and soapui running with the same jdk install? – Tim Jones Dec 19 '13 at 21:19
  • 1
    Also, if you are running on windows, certmgr is not the way to export certs. You want to use the keytool utility supplied with the jdk. certmgr manages certs used by the platform i.e. ie. – Tim Jones Dec 19 '13 at 21:20
  • 1
    How are you running your web service? – Tim Jones Dec 19 '13 at 21:22
  • 1
    @Tim Jones Yes, my client and soapUI are running with the same JDK install. I use 'keytool' to import certificates into the store, but exporting can be done using either `certmgr.msc` or [openssl](http://gagravarr.org/writing/openssl-certs/general.shtml). Both require a private key to convert from `.cer` to `.pfx` and rightly so. The problem is that a private key for a GlobalSign root CA is not available... so that may suggest that I am approaching this problem incorrectly. I am running my webservice through Tomcat 7. – Withheld Dec 19 '13 at 21:45
  • 1
    How was the tomcat cert created? Did you configure ssl according to the docs? – Tim Jones Dec 19 '13 at 22:04
  • @TimJones I wish I knew how the tomcat cert created. It was installed by a team member who has long left the department. Is there a way to find out from current state of the installation? – Withheld Dec 20 '13 at 13:15
  • 1
    If you pull up the wsdl in a browser, you should be able to view page info and pull up the cert details. Look to see who the issuing authority is. – Tim Jones Dec 20 '13 at 16:23
  • @TimJones Yes, that's exactly the certificate I was referring to all the time: At the bottom of the hierarchy there is my organization, `GlobalSign Organization CA - G2`, then `GlobalSign Root CA`. Then... I had an idea: Grep through the entire Tomcat folders hierarchy for certificate. Sure enough, 2 references to **SSLCertificateFile** and **SSLCertificateKeyFile** were found in a file named `server.xml`. But... they are commented out. (Re)Search continues.. – Withheld Dec 20 '13 at 18:55
  • And thanks to that discovery I have been able to search through the entire server (machine) and find the hidden treasure in the form of 3 files: `myorg.crt`, `key.pem`, `server.crt` and `server.key`. I believe that what I am interested in are **myorg.crt**, **key.pem**. Once the entire process is figured out and working, I will post this as answer, for future generations to come. – Withheld Dec 20 '13 at 19:09

1 Answers1

4

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).

Withheld
  • 4,603
  • 10
  • 45
  • 76