WCF Error "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case"

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.

The exception I'm getting is:

> General Error Occurred System.ServiceModel.CommunicationException: An error occurred while making the HTTP request

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.

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.

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)

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.

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.

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

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.

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.

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.

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

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: https://stackoverflow.com/questions/26389899/how-do-i-disable-ssl-fallback-and-use-only-tls-for-outbound-connections-in-net

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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 issue was simply the port number on the endpoint was incorrectly set to 8080. Changed it to 8443 and it worked.

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

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.

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.

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.