[英]WCF net.tcp SSL: none of the cipher suites supported by the client application are supported by the server
我有兩台電腦,我們稱之為PC1和PC2。
我編寫了一個服務端應用程序,它打開一個自托管的WCF net.tcp端點,使用X509證書進行保護。 我用於運輸安全的證書是“頒發給”任意名稱,例如:MY-TEST-SERVICE。
我還寫了一個客戶端應用程序來與服務進行通信。 它知道並指定服務將提供的DnsIdentity(MY-TEST-SERVICE),它使用服務用於傳輸安全性的相同X509證書。
當我在PC1上運行客戶端時,它可以與PC1和PC2上的服務一起使用。
當我在PC2上運行客戶端時,它與PC1上的服務一起工作,但與PC2上的服務的SSL握手失敗。
在PC2上打開WCF客戶端跟蹤,然后成功連接到PC1上的安全net.tcp服務,並且無法連接到PC2上的安全net.tcp服務,我可以確切地看到哪個步驟失敗了。
從PC2到PC1的成功握手的跟蹤報告: - 確定端點引用的身份 - 身份驗證成功
從PC2到PC2的失敗握手的跟蹤報告: - 套接字連接中止。 這可能是由...造成的 - 拋出異常
為什么身份驗證過程會失敗,但只有當客戶端和服務都在PC2上執行時?
我們最終發現了問題(我不知道它是否適用於您的確切情況)而不更改我們的代碼中的任何內容 - 在我們的例子中,它只是在沒有任何代碼更改的情況下開始了一天。
我們發現安裝了一個安裝了kb3102467
的Windows Update - 這是我們最終會使用的.NET Framework 4.6.1,並且可能會在每個人的機器上找到它。
似乎問題是TLS 1.2不再支持SHA512,因為它導致高CPU使用率。 我們可能需要為客戶端和服務器發布新的SSL證書。
作為解決方法,我們禁用了TLS 1.2:
這解決了我們的問題,同時仍然在機器上安裝了.NET F / W 4.6.1。
將客戶端和服務上的SecurityMode從Transport更改為Message已解決了原始問題,所有客戶端現在都可以使用所有服務。
這對我來說沒有意義,但無論如何,我有一個解決方案。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.