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

i @ wits' end on one.

fyi, work in infrastructure, not .net development, know little wcf , next nothing visual studio environment, don't think that's problem lies.

we have wcf service running on couple of iis 7.5 servers on our internal network. exposed outside world via reverse proxy on apache 2.2.15 on fedora 11. reverse proxy handles load balancing between iis servers, ssl.

the wcf service configured use transport level security, , iis servers have self-signed ssl certificates. reverse proxy not authenticate iis servers, , reason have ssl on iis servers in first place wsdl present correct location url.

we thought had working perfectly, there's 1 annoying , crucial exception: wsdl can't added service reference in visual studio on machines running windows vista or later. on xp machine, it's fine, later throws following error:

there error downloading '[url]'. operation has timed out metadata contains reference cannot resolved: '[url]'. error occurred while making http request [url]. due fact server certificate not configured http.sys in https case. caused mismatch of security binding between client , server. underlying connection closed: unexpected error occurred on send. received unexpected eof or 0 bytes transport stream. if service defined in current solution, try building solution , adding service reference again.

the wsdl accessible through browser, or through regular soap, on machine , without ssl complaints. it's visual studio has issue.

initial googling revealed might problem cipher suite vs used, suggesting vs on vista or later default attempt use tls1.0 in https connections, , if intermediary device didn't support protocol, drop request. not case, though. reverse proxy explicitly prefers tls1.0, , when viewing wsdl through browser, flags using tls1.0 connection.

having pointed proxy @ other functioning wcf services on different iis servers, same error occurs, leading me assume revolves around reverse proxy configuration. trouble seems identically configured reverse proxy carrying out same task elsewhere.

it's presumably transport level issue around how vs establishes https connections on different operating systems, don't know enough hazard guess might be. have suggestions?

well, embarrassing.

i'm sure there's unwritten cosmic law results in me finding incredibly simple solution problem i've been grinding away @ days ten minutes after posting on stackoverflow.

the servername directive in virtual host config didn't match url. did match certificate (which has subject alternative name, didn't throw ssl warnings), wasn't name accessing with.

i'm assuming there's extension of tls1.0 vs uses enforces this, isn't used browsers or soap clients. useful information else trying certificate has subject alternative names. wouldn't have come otherwise.