Why Schannel fails to receive handshake from the server?

Question

When I'm trying to pull from our git server I get this error:

fatal: unable to access 'xxx': OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to xxx

When this happened before I was able to solve it by simply restoring the system but this time my system restore points got deleted for some reason, and I can't do that either.

So this happens because something in my system settings related to SSL changes and I don't know why.

I have tried installing git to use windows cert. store instead of OpenSSL and I got this error:

fatal: unable to access 'xxx': schannel: failed to receive handshake, SSL/TLS connection failed

Same problem, different error message. The server is not sending back a hello message after the client hello. I thought this might happen because none of the cipher suites that I'm sending the server in the client hello message are supported by the server. So I've tried configuring a group policy and put the cipher suite the server is using first in order. But it didn't make any difference.

I am able to connect the git server's site through the browser. So my question is, what can I do to solve this problem?

Answer 1

In my case, I changed the .gitconfig from

[http] sslbackend = schannel

to

[http] sslbackend = openssl

Answer 2

I encountered the unable to access 'https://hostname.local/reponame.git/': schannel: failed to receive handshake, SSL/TLS connection failed error when I tried to use a http proxy for a git repo on the local network (which is not accessible through that particular proxy). I resetted the http.proxy setting to an empty string:

git config --global http.proxy ""

(Note that in my case, this was a global level setting, YMMV.)

Answer 3

You should try again, for testing, with the Git for Windows release 2.14.2 (June 21th, 2018), which adds code to force-ignore http.sslCAinfo when the ssl backend is set to schannel (so that the Windows Certificate Store is not ignored).
This is really only relevant when running with cURL v7.60.0 (or later).

See commit c5ad43e:

http: when using Secure Channel, ignore sslCAInfo by default

As of cURL v7.60.0, the Secure Channel backend can use the certificate bundle provided via http.sslCAInfo, but that would override the Windows Certificate Store. Since this is not desirable by default, let's tell Git to not ask cURL to use that bundle by default when the schannel backend was configured via http.sslBackend, unless useSSLCAInfo overrides this behavior.