WCF 错误“这可能是由于服务器证书在 HTTPS 情况下没有正确配置 HTTP.SYS

我有一个问题使用 WCF 调用从 Windows 服务到我的 WCF 服务在我的网络服务器上运行。这个电话已经工作了几个星期,但是突然停止工作,从那以后就没有工作了。

我得到的例外是:

发生一般错误 System.ServiceModel.CommunicationException: 发出 HTTP 请求时发生错误

然后它说

这可能是由于在 HTTPS 情况下没有使用 HTTP.SYS 正确配置服务器证书。这也可能是由于客户端和服务器之间的安全绑定不匹配造成的。

我在两端使用的安全性是 wsHttpBinding,没有任何类型的加密。它也只是在使用 HTTP 而不是 HTTPS,所以我不知道为什么它在抱怨 HTTPS。

内部异常堆栈的其余部分是:

WebException: 底层连接已关闭: 发送时发生意外错误。 --> System.IO.IOException: 无法将数据写入传输连接: 提供了一个无效的参数。 —— > 制度。网。插座。SocketException: 在 System 中提供了无效的参数。网。插座。插座。系统上的 MultipleSend (BufferOffsetSize []缓冲区,SocketFlagssocketFlags)。网。插座。网络流。MultipleWrite (BufferOffsetSize []缓冲区)

我还应该注意到,在我的程序中,这种情况发生在调用 Web 服务的“ Execute”行上——也就是说,只要我调用 Web 服务并传递给它包装好的 DataContractobject,它就会爆炸。

这个服务所做的就是传递大量的 XML (作为。NET 对象转换为客户端的调用) ,然后对其执行一些操作。大约有100-200k 的 XML 正在被传输。我已经将两端的数据大小限制提高到超过6兆,但这似乎没有帮助。

有什么想法吗?


关于这个问题的更多信息:

当我们在本地复制客户机环境时,我们发现无法上载大量的 XML,除非我们进行以下更改: 1. 在服务器上,将“ maxRequestLlength”设置为100MB (比我们发送的大得多) 2. 在客户端,我们将 dataContractSerializer 标记下的 maxItemsInObjectGraph 的值设置为“2147483646”。

通过这些更改,我们的本地安装上传成功。但是,客户端在其服务器上的安装仍然会失败。值得注意的是,一旦我们在服务器上更改 maxRequestLlength 值,我们的测试安装就开始抛出一个与 maxItemsInObjectGraph 设置特别相关的错误。然而在我们的客户端服务器上,仍然会发生原始的“ HTTPsys”错误。

正如我之前提到的,我们根本不使用 SSL,还有另外两个 Web 服务调用以相同的方式执行和上传 XML。但是,由于非工作服务调用传输更多数据,这似乎是一个大小问题。

但是,如果客户机遇到的问题与我们的测试安装遇到的问题相同,我就不明白为什么客户机错误消息不会与 ObjectGraph 错误相关。

有没有可能我们只是为客户机上的每个可能的错误获得了通用的“无效参数”“ HTTP.sys”错误(即。它实际上也得到了 objectGraph 错误,但只是没有显示出来?)

218532 次浏览

I've seen these particular exceptions related to Complex DataType issues, see the following post if you're passing around collections or enums:

Complex Data Types

If you are using transfer mode = streamed, try changing it to buffered.

If this is not the problem could you post your configuration.

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.

Good luck.

Since everything was working fine for weeks then stopped, I doubt this has anything to do with your code. Perhaps the error is occurring when the service is activated within IIS/ASP.NET, not when your code is called. The runtime could just be checking the configuration of the web site and throwing a generic error message which has nothing to do with the service.

My suspicion is that a certificate has expired or that the bindings are set up incorrectly. If the web site is mis-configured for HTTPS, whether your code uses them or not, you may be getting this error.

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.

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.

In IIS Manager, right-click the web site and choose Edit Bindings. If the entry for Port 443 has IP Address 127.0.0.1, change it to *.

Just recently experienced this:

System.ServiceModel.CommunicationException:

An error occurred while making the HTTP request to http://example.com/WebServices/SomeService.svc. 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.

---> System.Net.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 existing connection was forcibly closed by the remote host.

I found out from an administrator that the IIS application pool that was hosting the web service recycled automatically after running out of memory. The error on the client occurred when the application pool recycled.

Increasing the memory available to the application pool resolved the immediate issue.

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.

Supported protocols: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

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:

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

Taken from here: Disable SSL fallback and use only TLS for outbound connections in .NET? (Poodle mitigation)

Try to browse the service in the browser and in the Https mode, if it is not brow-sable then it proves the reason for this error. Now, to solve this error you need to check :

  • https port , check if it is not being used by some other resources (website)
  • Check if certificate for https are properly configured or not (check signing authority, self signed certificate, using multiple certificate )
  • check WCF service binding and configuration for Https mode

Our applications were recently forced off of SSL to TLS via a network appliance (F5) OS update. We fixed this error by re-generating the self-signed certs. Hope this helps someone in the future to resolve the issue as we spent multiple maintenance windows troubleshooting before arriving at the solution.

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).

To confirm this I simply logged the System.Net.ServicePointManager.SecurityProtocol before each request to each supplier.

Low and behold after restarting the service (or restarting the application pool) I would get the output Ssl3, Tls but after a few requests to the original supplier servers this changed to Ssl3 and requests to the TLS service gave the error.

To fix I simply did what user369142 suggested. Before each request to the new server:

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

and no more errors.

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:-)

Just recently experienced this:

System.ServiceModel.CommunicationException:

An error occurred while making the HTTP request to http://example.com/WebServices/SomeService.svc. 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.

---> System.Net.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 existing connection was forcibly closed by the remote host.

Our license of the bluecoat proxy was expired! so it was not possible to to reach the external party (internet).

We had the same issue and, in our case, it was resolved by reinstalling the certificate and creating the binding again. What lead us there was the fact that even getting a simple png image file on the site give the same error.

In my case I had to enable SchUseStrongCrypto for .Net This forces the server to make connection by using TLS 1.0, 1.1 or 1.2. Without SchUseStrongCrypto enabled the connection was trying to use SSL 3.0, which was disabled at my remote endpoint.

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

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.

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.

Our issue was simply the port number on the endpoint was incorrectly set to 8080. Changed it to 8443 and it worked.

Rather than explicitly setting the security protocol, a better way is to set the web.config <compilation targetFramework="4.5"> or higher.

I solved my problem by upgrading my .NetFramework version from 4.5.2 to 4.7.2.

We got this error from outer API...

Nothing above helped us, at the end the issue was that the request was too big!!

So check the error massage from server side if nothing above helping...