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?

Uni

Answer 1

In my case, I changed the .gitconfig from

[http] sslbackend = schannel

to

[http] sslbackend = openssl

Mia

I had similar issues and this solution seems to have worked. – Erectile

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

Internship

Yes in some cases this schannel message (also seen as curl error 35) is just an indirect indication that you are using a proxy for a URL that shouldn't go through the proxy. Adjusting your no_proxy environment variable can help. – Amoy

The perfect solution! – Morphogenesis

Answer 3

For me it seems to be related to some questionable software that came preinstalled on my device. Whether using OpenSSL or schannel, I was getting these intermittent issues with my Killer wireless network adapter when the prioritization engine was turned on. When I disabled it, all the problems disappeared, and other network operations seemed faster in general as well.

Killer Prioritization Engine

If you have this software on Windows, you can disable it by typing "Killer" in the start menu and launching "Killer Intelligence Center". On version 3.1222.726.1, you should see an option in Quick Settings on the right of the dashboard called "Prioritization Engine". Switch it off and test your git operations again. I'm not yet sure what happens if I simply uninstall this software.

Arbitress

I've had this problem on and off for weeks, on my Dell XPS. This fixed the problem straight away. Thanks! – Delphadelphi

How did you figure this out? – Packsaddle

@Packsaddle I knew it had to be something network related as I was also seeing intermittent network glitches in the browser for https web sites. The Killer Intelligence Center was the first thing I looked at. Just lucky I guess! – Arbitress

Answer 4

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.

Bettyannbettye

Won't be possible I'm afraid because this was a long time ago and I formatted my PC as a last resort. so I don't have this problem anymore. thanks for the answer though – Hollerman

Answer 5

If you're facing this issue in Visual Studio:

Open git settings and set the "Cryptographic network provider" to "OpenSSL"

Here's an example

Hassanhassell

Answer 6

I had the same issue (windows 10) and a reboot fixed the issue.

Hookworm

Answer 7

I my case I had this issue when using a local proxy (in my case px) to access the www (like github.com) but also using the same setup for our company github-site (git.example.org). I thought that this site would be also in the www, but it turned out that actually it was going trough a NAT-IP (internal). Therefore I had to exclude the internal IP address from my local proxy. Then it worked.

Wyatt

Answer 8

I was facing the same issue and then i tried setting url of repository where i needed to push,,, you just need to set the origin to gitHub repo use the following code

 git  remote set-url origin <URL of Your Repo>

Spectacle

Answer 9

One "weak" solution is to set GIT_SSL_NO_VERIFY:

export GIT_SSL_NO_VERIFY=true

Or on Windows, set the environment variable, either in the system or on the command line if using a command-line version of Git:

set GIT_SSL_NO_VERIFY=true

It will simply do what it says...

Piteous

This is not a solution, but a temporary workaround. Also great for testing if other problems prevent access to the remote repository. – Internship

Answer 10

In my case the NO_PROXY variable was not properly configured.

Isaisaac

Answer 11

In my case - same issue in jenkins job - I had the wrong user credentials provided.

Carcinomatosis

Answer 12

I have solution in my errors case.You can use command :

git push orgin destination_branch

Pigg

guess this answer is out of context – Carmody