CXF client: unable to find valid certification path to requested target

Question

I am trying to implement a client for a CXF-based web service that I also wrote.

My web service works great (tested working fine via soapUI), but running the client fails with the following:

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:323)

The message clearly points at a certificate problem, so I did a quick search and found the correct approach to supporting SSL in CXF and added the following to my Spring application context config XML:

  <http:conduit name="https://myserver/myws/register/soap?wsdl:{http://glob.reg.com/myws}.http-conduit">

    <http:tlsClientParameters>
      <sec:keyManagers keyPassword="password">
        <sec:keyStore type="JKS" password="password"
                      file="my/file/dir/Morpit.jks"/>
      </sec:keyManagers>
      <sec:trustManagers>
        <sec:keyStore type="JKS" password="password"
                      file="my/file/dir/Truststore.jks"/>
      </sec:trustManagers>
      <sec:cipherSuitesFilter>
        <!-- these filters ensure that a ciphersuite with
             export-suitable or null encryption is used,
             but exclude anonymous Diffie-Hellman key change as
             this is vulnerable to man-in-the-middle attacks -->
        <sec:include>.*_EXPORT_.*</sec:include>
        <sec:include>.*_EXPORT1024_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:include>.*_WITH_AES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
        <sec:exclude>.*_DH_anon_.*</sec:exclude>
      </sec:cipherSuitesFilter>
    </http:tlsClientParameters>
    <http:authorization>
      <sec:UserName>Betty</sec:UserName>
      <sec:Password>password</sec:Password>
    </http:authorization>
    <http:client AutoRedirect="true" Connection="Keep-Alive"/>

  </http:conduit>

And rebuilt the client. The client built successfully but I am still getting the same exact error and same exact stack trace, as if I never added this http:conduit thing.

I have not added the certificate to the store yet, and the path to the store is incorrect, but this is intentional as I just wanted to see how the re-built client reports this problem, adjusting to the new http:conduit information.

Instead, I was surprised to see that it was ignored altogether.

What have I missed?

What is the correct way of approaching this?

Update: I just noticed my applicationcontext.xml underlining http:conduit with this error message:

The prefix "http" for element "http:conduit" is not bound.

So I did a quick search and found a thread that suggests:

The client needs to configure the HTTP conduit with the keystore that contains the certificate of the STS, e.g.:

 <http:conduit name="https://localhost:.*">
      <http:tlsClientParameters disableCNCheck="true">
        <sec:trustManagers>
          <sec:keyStore type="jks" password="cspass" resource="clientstore.jks"/>
        </sec:trustManagers>
      </http:tlsClientParameters>
  </http:conduit>

Which reinforces what @GreyBeardedGeek wrote. Going to work on this now...

what you have missed is that you need to point to a valid truststore with a valid certificate that matches the server's cert. — GreyBeardedGeek, Dec 12 '13 at 21:57
@GreyBeardedGeek Thanks. Are you saying that unless I provide valid truststore with a valid certificate that matches the server's cert the generated/compiled code will treat the ` — Withheld, Dec 18 '13 at 13:35
No, I'm saying that your conduit specifies a truststore, so that truststore must contain the server's cert, with a valid certificate chain to a trusted cert, otherwise you're going to get the error that you're getting. — GreyBeardedGeek, Dec 18 '13 at 17:00
@GreyBeardedGeek I am going to try your suggestion now (see update above). I work on this *very* part time, so it takes me some time before I can act on a new insight. Thanks for your help so far. — Withheld, Dec 19 '13 at 18:21
@GreyBeardedGeek OK, I finally got to building an entire truststore from scratch, containing the entire certificate chain and included in the client's JAR, but that didn't help at all, issuing the same exact error. I had a feeling that was the wrong direction. The question now is how to I proceed from here? — Withheld, Jan 06 '14 at 21:29

score 3 · Accepted Answer · edited May 23 '17 at 12:21

Problem solved!

I followed this magicmonster article carefully (note the highlights on "older version of java", and the default password 'changeit'), to import the entire self signed certificate chain to the list of trusted certificates of the Java:

http://magicmonster.com/kb/prg/java/ssl/pkix_path_building_failed.html

With one very important additional twist: Do it for all certificates in the chain, not only the root! (in my case there were three: my organization's, the intermediate, and the root)

Then... go to the Spring application context config XML and modify the <http:conduit section to have the correct path (and password) for Java's cacerts file:

<http:tlsClientParameters>
  <sec:keyManagers keyPassword="changeit">
    <sec:keyStore type="JKS" password="changeit"
                  file="C:\Program Files (x86)\Java\jdk1.6.0_45\jre\lib\security\cacerts"/> 
  </sec:keyManagers>
  <sec:trustManagers>
    <sec:keyStore type="JKS" password="changeit"
                  file="C:\Program Files (x86)\Java\jdk1.6.0_45\jre\lib\security\cacerts"/> 
  </sec:trustManagers>

CXF client: unable to find valid certification path to requested target

1 Answers1

Linked