Visual Studio can't add WSDL resource in Windows Vista or later through Apache reverse proxy

I am at my wits' end on this one.

FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.

We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.

The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.

We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:

There was an error downloading '[URL]'. The operation has timed out Metadata contains a reference that cannot be resolved: '[URL]'. An error occurred while making the HTTP request to [URL]. 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 underlying connection was closed: An unexpected error occurred on a send. Received an unexpected EOF or 0 bytes from the 开发者_Go百科transport stream. If the service is defined in the current solution, try building the solution and adding the service reference again.

The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.

Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.

Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.

It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?

Well, that was embarrassing.

I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.

The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.

I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.