通过 https 解决 git 问题：例程：SSL23_GET_SERVER_HELLO
我在 centos 发行版上制作了自己的 git 服务器。 我可以在家里通过 git 协议联系服务器。但是当我尝试在办公室通过 https 访问时，我得到：
克隆到 /Users/vito/Documents/... 错误： 错误：14077458：SSL 例程：SSL23_GET_SERVER_HELLO：原因（1112）而 访问 https://[电子邮件受保护]/vitorepo.git/info/refs
致命：HTTP 请求失败
问题出在哪里？在我的服务器上还是在我的 Office-Mac 上？
I made my own git server on a centos distribution.
I can contact the server via git protocol at my home. But when I try to access via https at office I obtain:
Cloning into /Users/vito/Documents/... error:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while
accessing https://[email protected]/vitorepo.git/info/refsfatal: HTTP request failed
Where is the problem? On my server or on my office-mac?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当我尝试连接运行 openssl 1.0.0e 的 ubuntu 实例时，我从curl得到了完全相同的响应。我通过向curl命令添加-ssl3标志成功解决了该问题。
I got the exact same response from curl when trying to connect with an ubuntu instance running openssl 1.0.0e. I successfully resolved the problem by adding the -ssl3 flag to the curl command.
这似乎是作为客户端的旧版本 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
It seems that it's a compatibility problem between older version of OpenSSL (0.9.8) acting as a client and recent OpenSSL version (1.0.0) acting as a server with some specific options used by Curl on client side and Apache on server side.
It's probably due to some recent security fix in OpenSSL (probably the one against protocol downgrade attacks).
Try upgrading the OpenSSL library version on the client side to 1.0.0.
See:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
如果有人遇到 XMLRPC 的问题。
Daniel 的回答（强制使用 SSL 版本 3）为我解决了这个问题。只需在 clientXmlTransport_curl 选项 (C++) 中指定 XMLRPC_SSLVERSION_SSLv3 即可。
当我们将服务器升级到 OpenSSL 版本 1.0.1-4ubuntu5.5 并且客户端仍在运行 0.9.8o-5ubuntu1.7 时，问题就开始了。
In case anyone has this issue with XMLRPC.
Daniel's answer (forcing SSL version 3) solved the issue for me. just specify XMLRPC_SSLVERSION_SSLv3 in the clientXmlTransport_curl options (C++).
The problem began when we upgraded our server to OpenSSL version 1.0.1-4ubuntu5.5 and the clients were still running 0.9.8o-5ubuntu1.7.
我认为这是服务器上的主机名匹配问题。错误 1112 是 SSL_R_TLSV1_UNRECOGNIZED_NAME，来自 SNI 名称不匹配（有关 SNI 的信息）。我在curl中遇到了同样的问题 。
对我来说，解决方法是确保我在客户端上使用的名称与服务器上的 ServerName 或 ServerAlias 配置之一匹配。当然，这些命令是针对 apache 服务器的；我不知道你需要为 git 服务器做什么。但我怀疑您在家里和工作中使用的服务器名称是不同的，并且家庭名称是 git 服务器正在使用的规范名称（因此 SNI 正在工作）。
“真正的”修复可能需要在 git 中进行客户端更改，以允许忽略名称不匹配警告（就像您的浏览器已经这样做的方式）。
I believe this is a host-name matching issue on the server. Error 1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME, and comes from an SNI name mismatch (info on SNI). I was having the same issue in curl.
For me, the work around was to make sure the name I used on the client matched one of the ServerName or ServerAlias configurations on the server. Of course, these commands are for an apache server; I don't know what you need to do for a git server. But I suspect the server names you're using from home and work are different, and the home name is the cannonical name the git server is using (and therefore SNI is working).
The 'real' fix will probably take a client change in git to allow a way to ignore the name-mismatch warning (the way your browser already does).
不确定我是否遇到完全相同的问题，但错误消息是相同的。它似乎只发生在我设置了 git 服务器的 ubuntu 盒子上，出于某种原因，设置了 git 服务器的 centos 盒子没问题。
我三四天后才解决。事实证明，这是因为 git 的底层 Curl 库有一个损坏的 Keep-alive 实现（我最终转储了 HTTP 流量并手动验证了行为）。
简而言之，Curl（至少是我能找到的每个 Git 实现中使用的版本，包括命令行 git 和 eclipse 的 EGit）似乎没有正确解释 Connection 响应标头，或者更正确地说似乎没有正确解释缺少它的。
要解决此问题，您需要在 apache 内配置 SSL 虚拟主机，该主机为您的 GIT 存储库提供专门针对 git 的额外指令。在之前添加这些行。
不幸的是，你不能告诉 apache 降级到 HTTP/1.0 （会更干净），因为 Curl 无法处理这个问题，但你可以告诉它强制 Connection:close 对 Curl 知道如何处理的每个请求。
巧合的是，如果您尝试在不进行此更改的情况下直接测试 Curl，它似乎会起作用，因为它发出单个请求，然后中止。只有让curl 通过ssl 在同一个保持活动连接上执行两个请求，这个问题才会变得明显。
Not sure if I had exactly the same problem, but the error message was the same. It only seemed to be happening on the ubuntu box I set up a git server on, for some reason the centos box with a git server set up on it was fine.
I only just solved it after 3 or 4 days. It turns out to be because git's underlying Curl library has a broken Keep-alive implementation (I ended up dumping HTTP traffic and verifying the behaviour by hand).
In a nutshell Curl (at least the version used inside every Git implementation I could find, including command line git and eclipse's EGit) doesn't seem to correctly interpret the Connection response header, or more correctly doesn't seem to correctly interpret the absence of it.
To fix the problem you need to configure the SSL virtual host inside the apache that is serving your GIT repository with an extra directive specifically for git. Add these lines just before the </VirtualHost>.
You unfortunately can't tell apache to just downgrade to HTTP/1.0 (would be cleaner) because Curl can't handle that, but you can just tell it to force a Connection:close on every request which Curl does know how to handle.
In a misleading coincidence, if you try to test Curl directly without this change it will seem to work, because it makes a single request and then aborts. Only by getting curl to execute two requests on the same keep-alive connection over ssl will this problem become apparent.
我有同样的错误。根本原因似乎是客户端/服务器 openssl 版本不兼容。
我已经使用 apt-get Upgrade openssl 升级了我的服务器，并升级了我的 Windows git 安装。
windows git客户端组合
git版本1.9.4.msysgit.0，其中包含openssl版本：OpenSSL 0.9.8e 2007 年 2 月 23 日以及带有 openssl 版本的服务器：
OpenSSL 1.0.1c 10 May 2012似乎可以很好地协同工作。
I had the same error. The root cause seems to be incompatibility of client/server openssl versions.
I've upgraded my server with
apt-get upgrade openssland upgraded my windows git installation.The combination of windows git client
git version 1.9.4.msysgit.0, which contains openssl version:OpenSSL 0.9.8e 23 Feb 2007And server with openssl version:
OpenSSL 1.0.1c 10 May 2012seems to work fine together.