Visual Studio 无法通过 Apache 反向代理在 Windows Vista 或更高版本中添加 WSDL 资源
我对此一筹莫展。
仅供参考，我从事基础设施工作，而不是 .net 开发，所以我对 WCF 知之甚少，对 Visual Studio 作为一个环境几乎一无所知，但我不认为这就是问题所在。
我们的内部网络上的几台 IIS 7.5 服务器上运行着一个 WCF 服务。这是通过 Fedora 11 上的 Apache 2.2.15 上的反向代理向外界公开的。反向代理处理 IIS 服务器之间的负载平衡以及 SSL。
WCF 服务配置为使用传输级别安全性，并且 IIS 服务器具有自签名 SSL 证书。反向代理不会对 IIS 服务器进行身份验证，我们在 IIS 服务器上使用 SSL 的唯一原因是 WSDL 将显示正确的位置 URL。
我们以为它可以完美地工作，但有一个令人讨厌且至关重要的例外：在运行 Windows Vista 或更高版本的计算机上，WSDL 无法作为 Visual Studio 中的服务引用添加。在 XP 机器上，这很好，但是稍后会抛出以下错误：
下载时出错 '[网址]'。操作已超时 元数据包含一个参考 无法解析：“[URL]”。一个错误 发出 HTTP 请求时发生 到[网址]。这可能是由于 事实上，服务器证书是 未正确配置 HTTP.SYS 在 HTTPS 情况下。这也可以是 由安全性不匹配引起 客户端和客户端之间的绑定 服务器。底层连接是 已关闭：发生意外错误 发送时。收到意外的 EOF 或来自传输流的 0 字节。 如果服务定义在 当前的解决方案，尝试构建 解决方案并添加服务 再次参考。
WSDL 可以在任何机器上通过浏览器或常规 SOAP 访问，并且不会出现任何 SSL 问题。只是 Visual Studio 有问题。
初步谷歌搜索显示，这可能是 VS 使用的密码套件的问题，这表明 Vista 或更高版本上的 VS 默认情况下会尝试在 HTTPS 连接中使用 TLS1.0，如果中间设备不支持该协议，则会只会放弃请求。但事实绝对不是这样。反向代理明确首选 TLS1.0，即使通过浏览器查看 WSDL，它也会标记为使用 TLS1.0 进行连接。
将代理指向不同 IIS 服务器上其他正常运行的 WCF 服务后，会发生相同的错误，导致我认为它与反向代理配置有关。问题在于，它似乎与在其他地方执行相同任务的另一个反向代理进行了相同的配置。
这可能是关于 VS 如何在不同操作系统上建立 HTTPS 连接的一些传输级别问题，但我对此了解不够，无法冒险猜测这可能是什么。有人有什么建议吗？
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 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，这很尴尬。
我确信有一些不成文的宇宙法则让我找到了一个极其简单的解决方案，解决了我在 StackOverflow 上发布后十分钟左右一直苦心研究的问题。
虚拟主机配置中的 ServerName 指令与 URL 不匹配。它确实与证书匹配（该证书具有主题备用名称，因此它不会引发任何 SSL 警告），但这不是我访问它时使用的名称。
我假设 VS 使用某种 TLS1.0 扩展来强制执行此操作，但浏览器或 SOAP 客户端不使用该扩展。对于使用具有主题备用名称的证书尝试此操作的其他人来说，这可能是有用的信息。否则它就不会出现。
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.