我们正面临一个问题，我相信这是正确的地方。我们有一个负载均衡器（cisco 的），由于各种原因，负载均衡器（服务器）端的 SSL 配置设置为使用“SSLv3”协议版本。现在设置相同后，当我在 CHROME 浏览器中访问负载均衡器时，我可以访问这些页面，但是当我单击它们的安全图标时，我确实看到了以下消息。
“必须使用 ssl 3.0 重试连接” - 我使用 wireshark 查看了数据包捕获，我看到浏览器尝试 TLSv1 并从服务器接收到“致命警报”，说“protocol_version”，然后浏览器立即尝试 SSLv3 版本并完成握手。因此浏览器能够以客户端的身份进行协商。
但是，当我从 eclipse 设置一个独立的 java（尝试使用 1.6 和 1.7）客户端并尝试连接到服务器时，我得到了以下异常。
：收到致命警报：protocol_version javax.net.ssl.SSLException：收到致命警报：protocol_version
根据各种文档，我看到了两个选项
将 https.protocol 系统属性设置为 SSLv3。[这对我们有用，但问题是它会影响全局的出站 SSL 调用。我对另一个不适用于 SSLv3 的服务器进行了另一个出站 SSL 调用]
setEnabledprotocols() - 这也有效，但有时我们无法直接访问套接字（有时我们使用第三方生成存根，存根负责低级别的连接内容，因此无法访问该套接字）。
但我的实际问题是，如果默认情况下 TLSv1/SSLv3 和 SSLv2Hello（只是我相信的格式）在 java 中启用，为什么 JSSE 实现无法像 chrome 浏览器那样进行协商。这是预期的吗？如果浏览器正在这样做，我相信它应该是某些 SSL RFC 的一部分，如果是这样的话，这个“协商”的相同功能应该由 java 本身提供，对吗？
我确实浏览了这个http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java并且找不到任何部分握手期间的协商。
服务器端（负载平衡器）是否存在问题的可能性，即 i. 我看到服务器发送致命警报，但作为 cisco，我相信 ssl 实现应该是完美的，这是意料之中的。我错了吗？
问题发生在 java 1.6 和 1.7 中。如果需要更多信息来回答，请告诉我，我们很乐意提供帮助。