CXF客户端:无法找到到请求目标的有效证书路径 [英] CXF client: unable to find valid certification path to requested target

查看:221
本文介绍了CXF客户端:无法找到到请求目标的有效证书路径的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试为我也写过的基于CXF的Web服务实现客户端.

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

我的Web服务运行良好(测试通过soapUI可以正常工作),但是运行客户端失败,并显示以下内容:

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>

并重建客户端.客户端成功构建,但是我仍然得到相同的确切错误和相同的堆栈跟踪,就像我从未添加过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.

我还没有将证书添加到存储中,并且存储路径不正确,但这是有意的,因为我只是想查看重建的客户端如何报告此问题,以适应新的http:conduit信息.

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 is the correct way of approaching this?

更新:我刚刚注意到我的applicationcontext.xml在http:conduit下带有以下错误消息:

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:

客户端需要使用以下密钥库配置HTTP管道: 包含STS的证书,例如:

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>

这增强了@GreyBeardedGeek的写作.现在要进行此工作 ...

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

推荐答案

问题已解决!

我认真地关注了这篇魔术怪兽文章(请注意"java的较旧版本"和默认密码"changeit"),以将整个自签名证书链导入到Java的受信任证书列表:

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)

然后...转到 Spring应用程序上下文配置XML ,并修改<http:conduit部分,使其具有Java的证书文件的正确路径(和密码):

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客户端:无法找到到请求目标的有效证书路径的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆