通过 https 遇到 git 问题：routines:SSL23_GET_SERVER_HELLO答案

【问题标题】：git trouble via https: routines:SSL23_GET_SERVER_HELLO通过 https 遇到 git 问题：routines:SSL23_GET_SERVER_HELLO
【发布时间】：2011-12-07 16:38:29
【问题描述】：

我在 centos 发行版上制作了自己的 git 服务器。我可以在家中通过 git 协议联系服务器。但是当我尝试在办公室通过 https 访问时，我得到：

克隆到 /Users/vito/Documents/... 错误：错误：14077458：SSL 例程：SSL23_GET_SERVER_HELLO：原因（1112）而访问https://gitolite@myserverxyz.com/vitorepo.git/info/refs

致命：HTTP 请求失败

问题出在哪里？在我的服务器上还是在我的 office-mac 上？

【问题讨论】：

您的 git 服务器在您的家庭子网之外是否真的可用？比如说，你能在工作中成功地通过 SSH 访问它吗？
是的。我的服务器是一个公共服务器，所有有用的端口都打开了。

标签： macos git centos

【解决方案1】：

这似乎是作为客户端的旧版本 OpenSSL (0.9.8) 和作为服务器的最新 OpenSSL 版本 (1.0.0) 之间的兼容性问题，其中 Curl 在客户端和 Apache 在客户端使用了一些特定选项服务器端。

这可能是由于最近 OpenSSL 中的一些安全修复（可能是针对协议降级攻击的修复）。

尝试将客户端的 OpenSSL 库版本升级到 1.0.0。

见：

https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976

【讨论】：

【解决方案2】：

我认为这是服务器上的主机名匹配问题。错误 1112 是 SSL_R_TLSV1_UNRECOGNIZED_NAME，来自 SNI 名称不匹配 (info on SNI)。我有同样的issue in curl。

对我来说，解决方法是确保我在客户端使用的名称与服务器上的 ServerName 或 ServerAlias 配置之一匹配。当然，这些命令是针对 apache 服务器的；我不知道您需要为 git 服务器做什么。但是我怀疑您在家和工作中使用的服务器名称不同，并且家庭名称是 git 服务器正在使用的规范名称（因此 SNI 正在工作）。

“真正的”修复可能会在 git 中进行客户端更改，以允许忽略名称不匹配警告（您的浏览器已经这样做）。

【讨论】：

【解决方案3】：

尝试连接运行 openssl 1.0.0e 的 ubuntu 实例时，我从 curl 得到完全相同的响应。我通过在 curl 命令中添加 -ssl3 标志成功地解决了这个问题。

【讨论】：

你先生是个天才。我必须从 os x 执行此操作。你能解释一下为什么会这样吗？

【解决方案4】：

如果有人遇到 XMLRPC 的问题。

Daniel 的回答（强制 SSL 版本 3）为我解决了这个问题。只需在 clientXmlTransport_curl 选项 (C++) 中指定 XMLRPC_SSLVERSION_SSLv3。

当我们将服务器升级到 OpenSSL 版本 1.0.1-4ubuntu5.5 并且客户端仍在运行 0.9.8o-5ubuntu1.7 时，问题就开始了。

【讨论】：

【解决方案5】：

不确定我是否有完全相同的问题，但错误消息是相同的。它似乎只发生在我设置了 git 服务器的 ubuntu 盒子上，由于某种原因，带有 git 服务器的 centos 盒子很好。

我只是在 3 或 4 天后才解决它。原来是因为 git 的底层 Curl 库有一个损坏的 Keep-alive 实现（我最终转储了 HTTP 流量并手动验证了行为）。

简而言之，Curl（至少是我能找到的每个 Git 实现中使用的版本，包括命令行 git 和 eclipse 的 EGit）似乎没有正确解释 Connection 响应标头，或者更正确地说，似乎没有正确解释解释它的缺席。

要解决此问题，您需要在为您的 GIT 存储库提供服务的 apache 中配置 SSL 虚拟主机，并使用专门针对 git 的额外指令。在之前添加这些行。

 BrowserMatch "git" nokeepalive ssl-unclean-shutdown

不幸的是，你不能告诉 apache 只是降级到 HTTP/1.0（会更干净），因为 Curl 无法处理这个问题，但你可以告诉它强制一个 Connection:close 对每个 Curl 知道如何的请求处理。

巧合的是，如果您尝试在不进行此更改的情况下直接测试 Curl，它似乎可以工作，因为它会发出一个请求然后中止。只有让 curl 通过 ssl 在同一个 keep-alive 连接上执行两个请求，这个问题才会变得明显。

【讨论】：

【解决方案6】：

我有同样的错误。根本原因似乎是客户端/服务器 openssl 版本不兼容。我已经用apt-get upgrade openssl 升级了我的服务器并升级了我的 windows git 安装。

windows git客户端的组合 git version 1.9.4.msysgit.0，其中包含 openssl 版本： OpenSSL 0.9.8e 23 Feb 2007

和带有 openssl 版本的服务器： OpenSSL 1.0.1c 10 May 2012

似乎可以很好地协同工作。

【讨论】：