1 minute read

There’s an interesting edge condition we ran into at work last week around git connecting to a repo over HTTPS.

Specifically, the error error:[number]:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) was being returned to all clients after an upgrade of the git server.

After much Googling, including reading through a lot of comments on git and openssl and libcurl bug trackers, I came across this comment on libcurl bug 1037 that shed some light on the root cause.

Summary of problem:

When libcurl linked against OpenSSL 0.9.8* connects to Apache running mod_ssl linked against OpenSSL 1.0.*

AND

There is a mismatch between the host name in the client request and/or the Common Name (CN) in the SSL certificate and/or the ServerName in the Apache config

THEN

During the initial SSL handshake which determines SSL protocol version, OpenSSL returns a TLS Alert Warning about this mismatch

AND

libcurl interprets this as a fatal error and aborts the connection

Once figured out, the resolution was simple – make sure the CN in the SSL cert and the Apache ServerName (or a ServerAlias) match the host name being sent by the client (in this case, ServerName in Apache was set to 127.0.0.1:443).

This issue does not arise when OpenSSL 0.9.8* clients connect to an OpenSSL 0.9.8* server, or in any other combination than the affected one, which is why we didn’t see it before the upgrade.

OpenSSL 0.9.8* is still the version shipped with the current version of MacOS X. I didn’t find the bug in testing because I use a macports install of git and OpenSSL 1.0.1c, so everything worked fine for me. :(