xml WCF 错误“这可能是由于在 HTTPS 情况下未使用 HTTP.SYS 正确配置服务器证书”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2013880/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
WCF Error "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case"
提问by Sam Schutte
I'm having a problem using a WCF call from a Windows service to my WCF service running on my web server. This call has been working for a number of weeks, but then stopped working all of a sudden, and has not worked since.
我在使用从 Windows 服务到我的 Web 服务器上运行的 WCF 服务的 WCF 调用时遇到问题。此电话已工作数周，但突然停止工作，此后一直没有工作。
The exception I'm getting is:
我得到的例外是：
General Error Occurred System.ServiceModel.CommunicationException: An error occurred while making the HTTP request
发生一般错误 System.ServiceModel.CommunicationException: 发出 HTTP 请求时出错
and then it says
然后它说
This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
这可能是由于在 HTTPS 情况下未使用 HTTP.SYS 正确配置服务器证书这一事实。这也可能是由于客户端和服务器之间的安全绑定不匹配造成的。
The security I'm using on both ends is wsHttpBinding, without any kind of encryption. It also is just using HTTP - not HTTPS, so I'm not sure why it's complaining about HTTPS.
我在两端使用的安全性是 wsHttpBinding，没有任何类型的加密。它也只是使用 HTTP - 而不是 HTTPS，所以我不确定为什么它会抱怨 HTTPS。
The rest of the inner exception stack is:
内部异常堆栈的其余部分是：
SystemNet.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to write data to the transport connection: An invalid argument was supplied. ---> System.Net.Sockets.SocketException: An invalid argument was supplied at System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)
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[]) 提供了无效参数缓冲区）
I should also note that the point in my program where this occurs is on the "Execute" line of the call to the web service - that is, right as soon as I call the web service and pass it the wrapped up DataContract object, it blows up.
我还应该注意到，我的程序中发生这种情况的点是在调用 Web 服务的“执行”行上 - 也就是说，只要我调用 Web 服务并将其传递给包装好的 DataContract 对象，它炸毁。
All this service is doing is getting passed a large amount of XML (passed as a .NET object to the call on the client side), which it then does some work with. Probably about 100-200k of XML is being transmitted. I've raised the limits for the data sizes on both ends to over 6 megs, but that didn't seem to help.
这个服务所做的就是传递大量的 XML（作为 .NET 对象传递给客户端的调用），然后它会处理一些工作。大概有 100-200k 的 XML 正在传输。我已将两端的数据大小限制提高到超过 6 兆，但这似乎没有帮助。
Any ideas?
有任何想法吗？
Some more information on this issue:
关于这个问题的更多信息：
When we duplicate the client environment locally, we find that we cannot upload large amounts of XML unless we make the following changes: 1. On the server, set the "maxRequestLength" to 100 MB (way higher than we are sending) 2. On the client, we set the value of maxItemsInObjectGraph under the dataContractSerializer tag to "2147483646".
当我们在本地复制客户端环境时，我们发现除非我们进行以下更改，否则无法上传大量 XML： 1. 在服务器上，将“maxRequestLength”设置为 100 MB（比我们发送的高得多） 2. On在客户端，我们将 dataContractSerializer 标签下的 maxItemsInObjectGraph 的值设置为“2147483646”。
With these changes, our local installation uploads successfully. However, the client's install on their server still fails. What interesting to note is that once we made the maxRequestLength value change on the server, our test installation started throwing an error specifically relating to the maxItemsInObjectGraph setting. Whereas on our client's server, still the original "HTTP.sys" error is happening.
通过这些更改，我们的本地安装成功上传。但是，客户端在其服务器上的安装仍然失败。值得注意的是，一旦我们在服务器上更改了 maxRequestLength 值，我们的测试安装就开始抛出一个与 maxItemsInObjectGraph 设置相关的错误。而在我们客户端的服务器上，仍然发生原始的“HTTP.sys”错误。
As I noted before, we are not using SSL at all, and there are 2 other web services calls that execute and upload XML in the same way. However, since the non-working service call transmits more data, this appears to be a size issue.
正如我之前提到的，我们根本没有使用 SSL，还有 2 个其他 Web 服务调用以相同的方式执行和上传 XML。然而，由于非工作服务调用传输更多数据，这似乎是一个大小问题。
However, if the issue the client is having were the same one our test install had, I don't get why the client error message wouldn't be related to the ObjectGraph error.
但是，如果客户端遇到的问题与我们的测试安装遇到的问题相同，我不明白为什么客户端错误消息与 ObjectGraph 错误无关。
Is it possible that we're just getting the generic "invalid parameter" "HTTP.sys" error for every possible error on the client (ie. it's really getting the objectGraph error too, but just isn't showing it?)
对于客户端上的每个可能的错误，我们是否可能只是得到通用的“无效参数”“HTTP.sys”错误（即它确实也得到了 objectGraph 错误，但只是没有显示它？）
回答by user369142
We had this issue as the host server had been updated to use TLS V1.2 and we were connecting using standard SSL. This was an update made as part of pen testing of the sites. We saw the issue in code connection, but not browsers going to the wsdl. Below code resolved:
我们遇到了这个问题，因为主机服务器已更新为使用 TLS V1.2，并且我们使用标准 SSL 进行连接。这是作为网站渗透测试的一部分进行的更新。我们在代码连接中看到了这个问题，但在转到 wsdl 的浏览器中没有看到。下面的代码解决了：
if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Taken from here: How do I disable SSL fallback and use only TLS for outbound connections in .NET? (Poodle mitigation)
回答by Selwin Dedekind
I Had the same issue on a service running on IIS 7 the service connects to multiple suppliers servers (some SSL some not) when adding a new one of these (this new supplier was TLS 1.2) I would get the error after a few requests were made to the original servers (SSL).
我在 IIS 7 上运行的服务上遇到了同样的问题，该服务在添加其中一个（这个新供应商是 TLS 1.2）时连接到多个供应商服务器（有些是 SSL，有些不是），我会在几个请求后收到错误制作到原始服务器 (SSL)。
To confirm this I simply logged the System.Net.ServicePointManager.SecurityProtocolbefore each request to each supplier.
为了确认这一点，我简单地记录了System.Net.ServicePointManager.SecurityProtocol每个供应商的每次请求之前。
Low and behold after restarting the service (or restarting the application pool) I would get the output Ssl3, Tlsbut after a few requests to the original supplier servers this changed to Ssl3and requests to the TLS service gave the error.
低，在重新启动服务（或重新启动应用程序池）后，我会得到输出，Ssl3, Tls但是在向原始供应商服务器发出一些请求后，这更改为Ssl3并且对 TLS 服务的请求给出了错误。
To fix I simply did what user369142 suggested. Before each request to the new server:
为了解决这个问题，我只是按照 user369142 的建议做了。在对新服务器的每个请求之前：
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
and no more errors.
不再有错误。
回答by nsides
Had this issue with a true HTTPS binding and the same exception with "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case...". After double checking everything in code and config, it seems like the error message is not so misleading as the inner exceptions, so after a quick check we've found out that the port 443 was hooked by skype (on the dev server). I recommend you take a look at what holding up the request (Fiddler could help here) and make sure you can reach the service front (view the .svc in your browser) and its metadata.
有这个问题与真正的 HTTPS 绑定和相同的异常“这可能是由于在 HTTPS 情况下没有使用 HTTP.SYS 正确配置服务器证书......”。在仔细检查代码和配置中的所有内容后，错误消息似乎不像内部异常那样具有误导性，因此在快速检查后我们发现端口 443 被 Skype（在开发服务器上）挂钩。我建议您查看阻止请求的原因（Fiddler 可以在这里提供帮助）并确保您可以到达服务前端（在浏览器中查看 .svc）及其元数据。
Good luck.
祝你好运。
回答by ElektryczneNozyce
In my case I had to enable SchUseStrongCryptofor .Net
This forces the server to make connection by using TLS 1.0, 1.1 or 1.2. Without SchUseStrongCryptoenabled the connection was trying to use SSL 3.0, which was disabled at my remote endpoint.
就我而言，我必须启用SchUseStrongCrypto.Net 这会强制服务器使用 TLS 1.0、1.1 或 1.2 建立连接。如果未SchUseStrongCrypto启用，连接将尝试使用 SSL 3.0，但在我的远程端点已禁用。
Registry keys to enable use of strong crypto:
用于启用强加密的注册表项：
[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
回答by Joe Daley
For us, this error was because the developer's computer running the service had IIS configured to bind port 443 on 127.0.0.1 only.
对我们来说，这个错误是因为运行该服务的开发人员的计算机将 IIS 配置为仅在 127.0.0.1 上绑定端口 443。
In IIS Manager, right-click the web site and choose Edit Bindings. If the entry for Port 443has IP Address 127.0.0.1, change it to *.
在 IIS 管理器中，右键单击该网站并选择“编辑绑定”。如果端口条目443具有 IP 地址127.0.0.1，请将其更改为*。
回答by Sotiris Zegiannis
After a lot of searching and taking the lord's name in vain i finally got it.I have installed TLS 1.2 on the Server where my wcf service is running.My client was configured correctly but the it was built on .NET 4.5.1 whereas the wcf was on .NET 4.6.1. Both client and server must be at the same .NET Version if you are using TLS 1.2. I hope it helps someone someday:-)
经过大量搜索并徒劳地取了领主的名字后，我终于得到了它。我在运行 wcf 服务的服务器上安装了 TLS 1.2。我的客户端配置正确，但它构建在 .NET 4.5.1 上，而wcf 在 .NET 4.6.1 上。如果您使用 TLS 1.2，客户端和服务器必须是相同的 .NET 版本。我希望有一天它可以帮助某人:-)
回答by Shashank
Change your client application to 4.5 and above. IF you are 4.5 then use : System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 as needed or you can upgrade your application to above 4.6.1.
将您的客户端应用程序更改为 4.5 及更高版本。如果您是 4.5，则根据需要使用： System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 或者您可以将您的应用程序升级到 4.6.1 以上。
回答by atlas944
We had nearly this exact same issue occur recently and it turned out to be caused by Microsoft update KB980436 (http://support.microsoft.com/KB/980436) being installed on the calling computer. The fix for us, other than uninstalling it outright, was to follow the instructions at the KB site for setting the UseScsvForTls DWORD in the registry to 1. If you see this update is installed in your calling system you may want to give it a shot.
我们最近发生了几乎完全相同的问题，结果证明是由调用计算机上安装的 Microsoft 更新 KB980436 ( http://support.microsoft.com/KB/980436)引起的。除了完全卸载之外，我们的修复方法是按照 KB 站点上的说明将注册表中的 UseScsvForTls DWORD 设置为 1。如果您看到此更新安装在您的调用系统中，您可能想试一试.
回答by Fred Covely
I had this issue when running older XP SP3 boxes against both IIS and glassfish on Amazon AWS. Amazon changed their default load balancer settings to NOT enable the DES-CBC3-SHA cipher. You have to enable that on amazon ELB if you want to allow older XP TLS 1.0 to work against ELB for HTTPS otherwise you get this error. Ciphers can be changed on ELB by going to the listener tab in the console and clicking on cipher next to the particular listener you are trying to make work.
在 Amazon AWS 上针对 IIS 和 glassfish 运行较旧的 XP SP3 机器时，我遇到了这个问题。亚马逊更改了他们的默认负载均衡器设置，以不启用 DES-CBC3-SHA 密码。如果要允许旧的 XP TLS 1.0 与 ELB 对 HTTPS 工作，则必须在 amazon ELB 上启用它，否则会出现此错误。可以通过转到控制台中的侦听器选项卡并单击您尝试使用的特定侦听器旁边的密码来更改 ELB 上的密码。
回答by user1069816
If your WCF service is using .net framework 4.0 and someone has disabled TLS 1.0 on the server then you will see this exception. Due to .net 4.0 not supporting the higher versions of TLS.
如果您的 WCF 服务使用 .net framework 4.0 并且有人在服务器上禁用了 TLS 1.0，那么您将看到此异常。由于 .net 4.0 不支持更高版本的 TLS。
Supported protocols: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx
支持的协议：https: //msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx
