I'm inside my wits' finish on that one.

FYI, Sometimes in infrastructure, not .internet development, and so i know hardly any about WCF and then to nothing about Visual Studio being an atmosphere, however i don't believe this is where the issue lies.

There exists a WCF service running on a few IIS 7.5 servers on our internal network. This really is uncovered towards the outdoors world via reverse proxy on Apache 2.2.15 on Fedora 11. Overturn proxy handles load balancing between your IIS servers, in addition to SSL.

The WCF services are set up to make use of transport level security, and also the IIS servers have self-signed SSL certificates. Overturn proxy doesn't authenticate the IIS servers, and also the only reason we've SSL around the IIS servers to begin with is really the WSDL will show the right location URL.

We thought we'd it working perfectly, there is however one annoying and crucial exception: the WSDL can not be added like a service reference in Visual Studio on machines running Home windows Vista or later. With an XP machine, it's fine, but anything later throws the next error:

There is a mistake installing '[URL]'. The operation has timed out Metadata consists of a reference that can't be resolved: '[URL]'. A mistake happened while making the HTTP request to [URL]. This may be because of the proven fact that the server certificate is not set up correctly with HTTP.SYS within the HTTPS situation. This may be triggered with a mismatch from the security binding between your client and also the server. The actual connection was closed: An unpredicted error happened on the send. Received an unpredicted EOF or bytes in the transport stream. When the services are defined within the current solution, try building the solution and adding the service reference again.

The WSDL is obtainable via a browser, or through regular Cleaning soap, on any machine and with no SSL complaints. It is simply Visual Studio which has an problem.

Initial Searching says it may be an issue with the cipher suite that Versus used, recommending that Versus on Vista or later would automatically make an effort to use TLS1. in HTTPS connections, and when a middleman device did not support that protocol, it might just drop the request. This really is certainly not the situation, though. Overturn proxy clearly favors TLS1., as well as when viewing the WSDL via a browser, it flags as using TLS1. for that connection.

Getting pointed the proxy at other functioning WCF services on different IIS servers, exactly the same error happens, leading me to visualize it involves overturn proxy configuration. Unfortunately it appears to become in the same way set up to a different reverse proxy undertaking exactly the same task elsewhere.

It's most probably some transport level problem around how Versus determines HTTPS connections on different os's, however i simply have no idea enough about this to hazard a guess by what that could be. Anybody have suggestions?

Well, which was embarrassing.

I am sure there's some unwritten cosmic law that leads to me locating the incredibly simple means to fix an issue I have been grinding away at for several days about 10 mins after posting it on StackOverflow.

The ServerName directive within the virtual host config did not match the URL. It did match the certificate (with a Subject Alternative Title, therefore it did not provide any SSL alerts), but that wasn't the title I had been being able to access it with.

I am presuming there's some extension of TLS1. that Versus uses which makes sure this, which is not utilized by browsers or Cleaning soap clients. This really is most likely helpful information for other people trying this having a certificate which has Subject Alternative Names. It can't came up otherwise.