WSO2 ESB使用客戶端證書憑證發送介體

我們在IIS下有一個WCF服務，該服務受帶有客戶端證書（不是消息WS-Security，但由IIS本身）的傳輸安全（SSL）保護。我已將證書添加到wso2carbon.jks 每當執行發送介體時，請求超時。 IIS日誌只顯示錯誤500.0。如果在IIS配置中，我設置爲忽略客戶端證書一切正常。另外編碼的Java Axis2和.Net客戶端可以在打開ISS上的證書時正常工作。WSO2 ESB使用客戶端證書憑證發送介體

很可能我在通話中遺漏了一些東西。這種情況是否需要WS-policy？我將不勝感激任何幫助。

來源

2013-03-13 adnecs

其他信息 - 看起來像是碳運輸問題。在Hello Request 中檢查wireshark所有傳輸卡在握手中因此，服務器向ESB發送Hello，並且通信被阻塞。只有CommonsHTTPTransportSender能夠完成與服務器的握手（仍然沒有發送證書）因此，在Carbon中傳遞PassThrough和NIO http傳輸是否會成爲問題？ – adnecs 2013-03-14 09:00:36

終於找到了解決方法。

解決方案 在IIS上啓用SSLAlwaysNegoClientCert。這裏是一個好帖子：Make IIS require SSL client certificate during initial handshake

原因：如果客戶端訪問受保護的資源，IIS默認會重新協商SSL。 NIO和HttpPathThrough傳輸不允許重新協商（這是有道理的，因爲它是安全漏洞）。所以IIS沒有得到客戶端Hello，並且發出錯誤500（對於WSO2夥計們，爲什麼TryIt客戶端會掛起，直到超時呢？）

備註：我們並不總是可以在IIS端進行更改，所以它會好得多在WSO2 ESB中可用的傳輸將更靈活，因爲允許重新協商（也許我錯過了配置它的地方......）

來源

2013-03-15 05:16:00 adnecs

很高興聽到您爲此找到解決方法。但是，您是否嘗試使用以下附加參數啓動ESB： -Dsun.security.ssl.allowUnsafeRenegotiation = true（我在您指出的jira中找到它）。吉拉說它不起作用。但只是想檢查你是否嘗試過。 – 2013-03-15 07:11:14

Thx。此參數僅適用於核心Http傳輸，不會影響NIO或直通。所以在這種情況下沒有幫助。 – adnecs 2013-03-15 15:29:34

我對此進行了深入研究，發現問題仍然存在。 WSO2 ESB團隊意識到這一點，這是他們的路線圖，以妥善解決問題。他們還建議使用CallOut中介作爲解決方法。 – 2013-03-16 17:04:12

在這種情況下，WSO2 ESB充當客戶端。因此，您需要將證書導入WSO2 ESB的repository/resources/security文件夾中的client-truststore.jks。然後您的服務調用應該工作。

來源

2013-03-14 06:14:02

是的，它應該在client-truststore.jks中。您可以在ESB中啓用SSL debugginh，並查看ESB中哪一點出錯。有資源可以解釋如何啓用SSL調試日誌。 – 2013-03-14 17:58:31

從所有調試看來，問題是PassThrough和NIO https傳輸不支持（bug？）SSL重新協商。當客戶端通過發送Hello請求向證書保護的資源服務器請求重新協商請求時。克林特沒有迴應，一切都卡住了。核心http傳輸完成重新協商。找到您打開的錯誤wso2.org/jira/browse/CARBON-11041似乎是相關的。你能解決這個問題嗎？這對我們來說確實是一個阻礙，所以我非常感謝幫助。 – adnecs 2013-03-15 02:16:41

WSO2 ESB使用客戶端證書憑證發送介體

回答

相關問題