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

Question

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

Gaytan

You say it stopped working, has any code or config changed that may have been responsible for this? can you post some code for the method you're calling with datatypes that are being passed? – Versatile

I'll dig that up and post it. I think I'm basically passing an array of "AppointmentData" objects, which are defined in the DataContract stuff. Certainly complex objects though, so I'll check out your post. Thanks! – Gaytan

Oh, and no code or config has been altered - worked fine for weeks, and then just stopped. It's possible the client's firewall settings were changed too, but what's weird is the service that is making the WCF call can call 2 other WCF service methods, and also has the ability to send me an email with the exception contents...so it's getting out on 2 of the 3 WCF calls, but not the last. – Gaytan

I'm always leery of "General Errors" that then suggest a possibility because you don't really know whether the suggestion is a red herring or not. Can you test by setting the security = none? If the service call works, it tells us the cert (or at least the security) is an issue. I'd also like to see the config on both sides. – Carnot

I'll have to check, but I'm pretty sure security is already set to none... – Gaytan

Have you enabled tracing and then used the ServiceTraceViewer to analyze the logs? You get much, much better information about these horrible general errors that way. – Taintless

i had the same error and i've set the maxItemsInObjectGraph at about 200000 and it worked. my configuration was transport with message security and signed certificate by an authority i have issued. on localhost the call to webservice worked but when an outsider called the sameservice i had that error with http.sys. i identified maxItemsInObjectGraph as the sole problem, especially when set on the client. – Theorize

I turned on all the logging and all it told me was a bunch of unrelated events and the exact same exception. – Testerman

I used Fiddler and found out that my problem was down to username and password authentication. The certificate config error message was a bit of a misnomer. – Womankind

You can also see the errors in the event viewer under Administrative events, in my case this link solved the issue : blogs.technet.microsoft.com/silvana/2014/03/14/… – Came

I faced a similar issue & have posted findings along with a solution here: #50752910 I had looked at this thread before posting there. – Coinsurance

Answer 1

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)

Cardio

Thank you! This helped me. I had to set this if calling a C# DLL making SOAP call from a C++ app. If same C# DLL was called from C# app, this was not needed. – Chapter

in my case: a) i needed to add using System.Net to my file. b) the value of SecurityProtocol was "Default". I decided to remove the "if" and assign SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 without asking first. HTH, Marcelo – Repressive

If you are using .net 3.5 then SecurityProtocolType.Tls12 is not available but there is a workaround: https://mcmap.net/q/212429/-net-framework-3-5-and-tls-1-2 – Delius

Answer 2

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.

Vorticella

You will need a minimum of .NET 4.5+ to use TLS 1.2+. Source: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support – Deodorant

Thank you so much, could it be used with integers for the enumeration instead: System.Net.ServicePointManager.SecurityProtocol =123=> enum1|enum2,etc.. For other frameworks? – Rankins

You don’t need to set this before each request - just set it once in application start event - it’s a static property you’re setting. – Cardio

Answer 3

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

Tippets

Helped me w BizTalk 2020 + .Net Framework 4.7.2! Thanks! Don't forget to restart host instances (machine restart not needed). – Betsybetta

Answer 4

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.

Pomander

Answer 5

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

Menken

Another things to highlight, double-click on the https binding and choose SSL certificate below. It was my issue that there had been 'not selected'. – Umbilication

Answer 6

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.

Odine

Answer 7

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

Moskow

This would have to be a bug if that was the case, the protocol shouldn't differ based on the .NET version, and not to mention services or clients that aren't even using .NET. – Kittrell

This hint solved my problem. I had a WPF project with a reference to another project B. Project B was 4.5.2 and the WPF project was 4.6.1. Making both 4.5.2 solved the problem. – Carmacarmack

Answer 8

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.

Ivetteivetts

Were your calls using HTTPS? Or were they unencrypted as the OP's? – Ferdie

Answer 9

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

Satirize

Actually there is a workaround, you can still use: ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2 and it will work on NET 4.0. – Stenographer

@Stenographer your comment solved my issue for a .NET 4.0 app trying to make a SOAP request to an endpoint that was recently converted from http to https. Supported by blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support – Complete

You sir, have just made my first beer this evenning all the more sweeter. I thank you – Indigestion

Answer 10

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.

Milkwort

Answer 11

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

Gwendolin

Answer 12

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

Shurlock

Answer 13

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

Versatile

We looked into the data type issue - we're just sending plain old .NET objects that are defined in our dataContract - no enumerables or stuff like that. We installed some of the debug tracing tools mentioned in this article though, and could see our 2 working calls coming through, but nothing appeared at all for the 3rd "non-working" call. This indicates to me that it's not even getting off the client machine at all. – Gaytan

@SamSchutte: was this error ever resolved? Could you please provide what the solution was? – Hoodoo

Answer 14

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

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

Vernalize

Answer 15

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.

Kenyakenyatta

Answer 16

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

Frankly

Answer 17

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

Kingpin

Answer 18

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

Horlacher

Answer 19

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.

Dibbuk

Answer 20

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.

Oubre

Answer 21

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

Harrington

Answer 22

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.

Filial

Answer 23

I had another scenario: if this error came from svcutil.exe then you need to create file svcutil.exe.config along side svcutil.exe with following content:

<?xml version ="1.0"?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
  </runtime>
</configuration>

Mariann