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