WCF 錯誤“這可能是由於在 HTTPS 情況下未使用 HTTP.SYS 正確配置服務器證書”

Question

我在使用從 Windows 服務到我的 Web 服務器上運行的 WCF 服務的 WCF 調用時遇到問題。 此電話已工作數周，但突然停止工作，此后一直沒有工作。

我得到的例外是：

發生一般錯誤 System.ServiceModel.CommunicationException: 發出 HTTP 請求時出錯

然后它說

這可能是由於在 HTTPS 情況下未使用 HTTP.SYS 正確配置服務器證書這一事實。 這也可能是由於客戶端和服務器之間的安全綁定不匹配造成的。

我在兩端使用的安全性是 wsHttpBinding，沒有任何類型的加密。 它也只是使用 HTTP - 而不是 HTTPS，所以我不確定為什么它會抱怨 HTTPS。

內部異常堆棧的其余部分是：

SystemNet.WebException：基礎連接已關閉：發送時發生意外錯誤。 ---> System.IO.IOException: 無法將數據寫入傳輸連接：提供的參數無效。 ---> System.Net.Sockets.SocketException：System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[]) 提供了無效參數緩沖區）

我還應該注意，我的程序中發生這種情況的點是在調用 Web 服務的“執行”行上 - 也就是說，只要我調用 Web 服務並將其傳遞給包裝好的 DataContract 對象，它炸毀。

這個服務所做的就是傳遞大量的 XML（作為 .NET 對象傳遞給客戶端的調用），然后它會處理一些工作。 大概有 100-200k 的 XML 正在傳輸。 我已將兩端的數據大小限制提高到超過 6 兆，但這似乎沒有幫助。

有任何想法嗎？

---

關於這個問題的更多信息：

當我們在本地復制客戶端環境時，我們發現除非我們進行以下更改，否則無法上傳大量 XML： 1. 在服務器上，將“maxRequestLength”設置為 100 MB（比我們發送的高得多） 2. On在客戶端，我們將 dataContractSerializer 標簽下的 maxItemsInObjectGraph 的值設置為“2147483646”。

通過這些更改，我們的本地安裝成功上傳。 但是，客戶端在其服務器上的安裝仍然失敗。 值得注意的是，一旦我們在服務器上更改了 maxRequestLength 值，我們的測試安裝就開始拋出一個與 maxItemsInObjectGraph 設置相關的錯誤。 而在我們客戶端的服務器上，仍然發生原始的“HTTP.sys”錯誤。

正如我之前提到的，我們根本沒有使用 SSL，還有 2 個其他 Web 服務調用以相同的方式執行和上傳 XML。 然而，由於非工作服務調用傳輸更多數據，這似乎是一個大小問題。

但是，如果客戶端遇到的問題與我們的測試安裝遇到的問題相同，我不明白為什么客戶端錯誤消息與 ObjectGraph 錯誤無關。

對於客戶端上的每個可能的錯誤，我們是否可能只是得到通用的“無效參數”“HTTP.sys”錯誤（即它確實也得到了 objectGraph 錯誤，但只是沒有顯示它？）

Answer 1

我們遇到了這個問題，因為主機服務器已更新為使用 TLS V1.2，並且我們使用標准 SSL 進行連接。 這是作為網站滲透測試的一部分進行的更新。 我們在代碼連接中看到了這個問題，但在轉到 wsdl 的瀏覽器中沒有看到。 下面的代碼解決了：

if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

取自此處： 如何在 .NET 中禁用 SSL 回退並僅將 TLS 用於出站連接？ （貴賓犬緩解）

Answer 2

我在 IIS 7 上運行的服務上遇到了同樣的問題，該服務在添加其中一個（這個新供應商是 TLS 1.2）時連接到多個供應商服務器（有些是 SSL，有些不是），我會在幾個請求后收到錯誤制作到原始服務器 (SSL)。

為了確認這一點，我在對每個供應商的每個請求之前簡單地記錄了System.Net.ServicePointManager.SecurityProtocol 。

低，在重新啟動服務（或重新啟動應用程序池）后，我會得到輸出Ssl3, Tls但是在向原始供應商服務器發出一些請求后，這更改為Ssl3並且對 TLS 服務的請求給出了錯誤。

為了解決這個問題，我只是按照 user369142 的建議做了。 在對新服務器的每個請求之前：

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

不再有錯誤。

Answer 3

就我而言，我必須為 .Net 啟用SchUseStrongCrypto這會強制服務器使用 TLS 1.0、1.1 或 1.2 建立連接。 在沒有啟用SchUseStrongCrypto ，連接試圖使用 SSL 3.0，但在我的遠程端點上已禁用。

用於啟用強加密的注冊表項：

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Answer 4

有這個問題與真正的 HTTPS 綁定和相同的異常“這可能是由於在 HTTPS 情況下沒有使用 HTTP.SYS 正確配置服務器證書......”。 在仔細檢查代碼和配置中的所有內容后，錯誤消息似乎不像內部異常那樣具有誤導性，因此在快速檢查后我們發現端口 443 被 Skype（在開發服務器上）掛鈎。 我建議您查看阻止請求的原因（Fiddler 可以在這里提供幫助）並確保您可以到達服務前端（在瀏覽器中查看 .svc）及其元數據。

祝你好運。

Answer 5

對我們來說，這個錯誤是因為運行該服務的開發人員的計算機將 IIS 配置為僅在 127.0.0.1 上綁定端口 443。

在 IIS 管理器中，右鍵單擊該網站並選擇“編輯綁定”。 如果端口443的條目具有 IP 地址127.0.0.1 ，請將其更改為* 。

Answer 6

經過大量搜索並徒勞地取了領主的名字后，我終於得到了它。我在運行 wcf 服務的服務器上安裝了 TLS 1.2。我的客戶端配置正確，但它構建在 .NET 4.5.1 上，而wcf 在 .NET 4.6.1 上。 如果您使用 TLS 1.2，客戶端和服務器必須是相同的 .NET 版本。 我希望有一天它可以幫助某人:-)

Answer 7

將您的客戶端應用程序更改為 4.5 及更高版本。 如果您是 4.5，則根據需要使用：System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0，或者您可以將您的應用程序升級到 4.6.1 以上。

Answer 8

我們最近發生了幾乎完全相同的問題，結果證明是由調用計算機上安裝的 Microsoft 更新 KB980436 ( http://support.microsoft.com/KB/980436 ) 引起的。 除了完全卸載之外，我們的修復方法是按照 KB 站點上的說明將注冊表中的 UseScsvForTls DWORD 設置為 1。如果您看到此更新安裝在您的調用系統中，您可能想試一試.

Answer 9

如果您的 WCF 服務使用 .net framework 4.0 並且有人在服務器上禁用了 TLS 1.0，那么您將看到此異常。 由於 .net 4.0 不支持更高版本的 TLS。

支持的協議： https : //msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

Answer 10

在 Amazon AWS 上針對 IIS 和 glassfish 運行較舊的 XP SP3 機器時，我遇到了這個問題。 亞馬遜更改了他們的默認負載均衡器設置，以不啟用 DES-CBC3-SHA 密碼。 如果您希望允許較舊的 XP TLS 1.0 與 ELB 對 HTTPS 工作，則必須在 amazon ELB 上啟用它，否則您會收到此錯誤。 可以通過轉到控制台中的偵聽器選項卡並單擊您嘗試使用的特定偵聽器旁邊的密碼來更改 ELB 上的密碼。

Answer 11

與明確設置安全協議不同，更好的方法是設置 web.config <compilation targetFramework="4.5"> 或更高版本。

Answer 12

我通過將 .NetFramework 版本從 4.5.2 升級到 4.7.2 解決了我的問題。

Answer 13

我已經看到這些與復雜數據類型問題相關的特殊異常，如果您正在傳遞集合或枚舉，請參閱以下帖子：

復雜數據類型

Answer 14

如果您使用傳輸模式 = 流式傳輸，請嘗試將其更改為緩沖。

如果這不是問題，您可以發布您的配置。

Answer 15

由於一切正常工作數周然后停止，我懷疑這與您的代碼有關。 錯誤可能是在 IIS/ASP.NET 中激活服務時發生的，而不是在調用您的代碼時發生。 運行時可能只是檢查網站的配置並拋出與服務無關的通用錯誤消息。

我懷疑證書已過期或綁定設置不正確。 如果網站為 HTTPS 配置錯誤，無論您的代碼是否使用它們，您都可能收到此錯誤。

Answer 16

嘗試在瀏覽器和 Https 模式下瀏覽服務，如果不是 browsable 則證明此錯誤的原因。 現在，要解決此錯誤，您需要檢查：

• https 端口，檢查它是否未被某些其他資源（網站）使用
• 檢查 https 的證書是否正確配置（檢查簽名權限、自簽名證書、使用多個證書）
• 檢查 WCF 服務綁定和 Https 模式的配置

Answer 17

我們的問題只是端點上的端口號被錯誤地設置為 8080。將其更改為 8443 並且它起作用了。

Answer 18

我們從外部 API 收到此錯誤...

以上都沒有幫助我們，最后的問題是請求太大了！！

因此，如果沒有任何幫助，請檢查服務器端的錯誤消息...

Answer 19

最近剛經歷過這個：

System.ServiceModel.CommunicationException:

向http://example.com/WebServices/SomeService.svc發出 HTTP 請求時發生錯誤。 這可能是由於在 HTTPS 情況下未使用 HTTP.SYS 正確配置服務器證書這一事實。 這也可能是由於客戶端和服務器之間的安全綁定不匹配造成的。

---> System.Net.WebException: 基礎連接已關閉：發送時發生意外錯誤。

---> System.IO.IOException: 無法將數據寫入傳輸連接：遠程主機強行關閉了現有連接。

我從管理員那里發現托管 Web 服務的 IIS 應用程序池在內存不足后會自動回收。 應用程序池回收時發生客戶端錯誤。

增加應用程序池可用的內存解決了眼前的問題。

Answer 20

我們的應用程序最近通過網絡設備 (F5) 操作系統更新從 SSL 強制轉換為 TLS。 我們通過重新生成自簽名證書修復了此錯誤。 希望這有助於將來有人解決問題，因為我們在找到解決方案之前花費了多個維護窗口進行故障排除。

Answer 21

最近剛經歷過這個：

System.ServiceModel.CommunicationException:

向http://example.com/WebServices/SomeService.svc發出 HTTP 請求時發生錯誤。 這可能是由於在 HTTPS 情況下未使用 HTTP.SYS 正確配置服務器證書這一事實。 這也可能是由於客戶端和服務器之間的安全綁定不匹配造成的。

---> System.Net.WebException: 基礎連接已關閉：發送時發生意外錯誤。

---> System.IO.IOException: 無法將數據寫入傳輸連接：遠程主機強行關閉了現有連接。

我們的 bluecoat 代理許可證已過期！ 因此無法聯系到外部方（互聯網）。

Answer 22

我們遇到了同樣的問題，在我們的例子中，它通過重新安裝證書並再次創建綁定來解決。 導致我們出現的事實是，即使在網站上獲取一個簡單的 png 圖像文件也會出現相同的錯誤。