git trouble via https: routines:SSL23_GET_SERVER_HELLO

Question

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/refs

fatal: HTTP request failed

Where is the problem? On my server or on my office-mac?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

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>.

 BrowserMatch "git" nokeepalive ssl-unclean-shutdown

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.