在基於cxf的客戶端cacerts與jks

我試圖配置我的基於cxf的客戶端與我寫的（也是基於cxf的）web服務進行通信。在基於cxf的客戶端cacerts與jks

Web服務本身的工作完美無缺，通過soapUI進行測試。

然而，客戶建立罰款，但調用throws a SunCertPathBuilderException。

懷疑這與提供到包含服務器的證書一個trustore的有效路徑，具有有效證書鏈到受信任的證書做，我第一次嘗試到該服務器的證書導出到PFX讓我能將其導入項目自己的.jks。原來這是不可能的，因爲它需要一個私有密鑰，導出實用程序（certmgr.msc）將其灰顯爲for some reason。

所以我試着從另一個方向解決問題：我知道soapUI通過SSL與Web服務進行通信沒有問題，並且我沒有爲它安裝任何證書，所以它必須滿足於根證書（CA）已存在於其cacerts文件中。

但是... http:conduit部分我的基於CXF的應用程序上下文.xml需要JKS類型的密鑰庫......所以它看起來像我處於catch 22情況。

除非cacerts文件是JKS類型？

如果沒有，是否有辦法將證書從cacerts轉換或導出爲.jks？

解決這個問題的正確方法是什麼？

來源

2013-12-19 Withheld

你的客戶端和soapui是否運行相同的jdk安裝？ –

另外，如果您在Windows上運行，certmgr不是導出證書的方式。您想使用隨jdk提供的keytool實用程序。 certmgr管理平臺使用的證書，即。 –

你如何運行你的網絡服務？ –

要找到cacerts文件的類型，只是使用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

所以答案是：

是，cacerts是JKS類型。
沒有必要將cacerts轉換爲JKS，因爲它已經是這種格式。
一種方法來解決，這是找到Tomca'ts conf目錄server.xml文件（在客戶端的服務器），然後找出如何證書或信任存儲在<Connector元素中指定，然後...

如果需要在客戶端的信任存儲中添加新內容，請查找原始的.crt以及用於在客戶端的服務器上安裝證書的密鑰文件。否則，只需使客戶端的應用程序上下文XML指向soapUI使用的相同信任存儲（因爲它已被證明正在工作）。

來源

2013-12-26 20:06:29 Withheld

在基於cxf的客戶端cacerts與jks

回答

相關問題