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

wcf ierrorhandler
exception handling in wcf using fault contract
wcf custom error page
wcf connection error
error handling in wcf rest service
wcf custom errors
providefault wcf
faultexception<validationfault

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

WCF Exception Handling Tutorial and Best Practices, Proper WCF error handling requires implement both best practices. Handle and collect all server side exceptions; Utilize fault contracts to provide  Windows Communication Foundation (WCF) Web HTTP error handling enables you to return errors from WCF Web HTTP services that specify an HTTP status code and return error details using the same format as the operation (for example, XML or JSON).

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.

Best Ways For WCF Exception Handling, Using FaultException: Best Option. Using IErrorHandler: Only when the exception can't be handled by Fault. Exceptions inside a WCF Service. A WCF service developer may encounter some unforeseen errors which require reporting to the client in a suitable manner. Such errors, known as exceptions, are normally handled by using try/catch blocks, but again, this is very technology specific.

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.

WCF: Error Handling and FaultExceptions, Suppose I write a WCF web service with no try-catch blocks and no error handling. What happens when my web service throws an exception? You do not define a binding in your service's config, so you are getting the default values for wsHttpBinding, and the default value for securityMode\transport for that binding is Message.

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

Exception handling in WCF, Take advantage of fault exceptions in WCF to send user friendly error messages to the service consumer when an exception has occured. Message Logging/tracing: WCF writes an event to the event log when trace and message logging fails. However, not every trace failure triggers an event. To prevent the event log from being completely filled with traces failures, WCF implements a 10 minute blackout period for such an event.

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

WCF - Exception Handling, A WCF service developer may encounter some unforeseen errors which is used to communicate the error message from the service to the client in WCF. I have a solution with 2 projects, one of them is a plain old html with jquery ajax call while the other is a WCF service. The html page will issue a ajax call to the WCF service to get a json string and use it for display purpose. Now the issue is whenever i run in debug mode, both the html page and the WCF will be started with different port.

WCF, How to propagate a user-friendly error message to the client, who consumes the WCF Service? How to send business rule validation messages  Windows Communication Foundation (WCF) applications handle error situations by mapping managed exception objects to SOAP fault objects and SOAP fault objects to managed exception objects.

How do I create a global exception handler for a WCF Services , You can create a WCF error-logger by implementing IErrorHandler and associating it with the service; typically (for logging) you would return false from  Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application.

Error Handling with WCF Service and Client Application, First, if you want to pass the exception over the protocol, you have to wrap it in a faultexception, otherwise you will get a server error. Use the FaultContract  Proper WCF error handling involves using best practices on the server and client side. You need to make sure that you properly collect exceptions happening on the server and also return them to the client to handle.

Comments
  • 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?
  • 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!
  • 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.
  • 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.
  • I'll have to check, but I'm pretty sure security is already set to none...
  • 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
  • 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?
  • 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.
  • 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.
  • Were your calls using HTTPS? Or were they unencrypted as the OP's?
  • Actually there is a workaround, you can still use: ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2 and it will work on NET 4.0.
  • @F34R 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
  • 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.
  • @SamSchutte: was this error ever resolved? Could you please provide what the solution was?