Github unable to access SSL connect error
Asked Answered
C

3

40

I have been using git lots for the last few months. git push worked 12 hours ago now all attempts generate errors, with verbose it produces this:

GIT_CURL_VERBOSE=1 git push
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
* Trying 192.30.253.112... * Connected to github.com (192.30.253.112) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
   CApath: none
* NSS error -12190
* Expire cleared
* Closing connection #0
fatal: unable to access 'https://github.com/waveney/wmff/': SSL connect error

Any bright ideas? No changes to server from when it worked to now, restart made no difference

Coreencorel answered 22/2, 2018 at 22:38 Comment(2)
NSS -12190 is "Peer reports incompatible or unsupported protocol version." Prob dupe #48938519 and #48938571 both of which cite githubengineering.com/crypto-removal-notice which permanently disabled TLSv1.0 and 1.1 today at 19:00 UTC, about 3 hours before your post, and gives fixes for some clients.Garonne
Yes that seems to be what happened - it is the oldest of my servers.Coreencorel
A
120

I was having the same problem on various CentOS 6 VM's and it turned out to be an issue with stale curl and nss libraries (thanks to this thread for pointing me in the right direction: cURL SSL connect error 35 with NSS error -5961).

The fix that worked for me is just:

yum update -y nss curl libcurl
Afterword answered 23/2, 2018 at 1:1 Comment(5)
yum update -y worked for me, followed by re-logging in.Diller
This worked on CentOS 7 too. Getting "Peer reports incompatible or unsupported protocol version" when doing a git clone.Andress
git clone gives me error "fatal: unable to access 'github.com/tensorflow/tensorflow': Peer reports incompatible or unsupported protocol version". Then I run the command yum update -y nss curl libcurl. This gives me message: "Loaded plugins: versionlock No packages marked for update". Any help on how to resolve this.Secessionist
Also need to update ca-certificates and openssl.Caundra
how to do in Ubuntu 18.04 it will not allow yum udpateZing
K
0

yum update -y worked for me to fix a fatal error when running git clone.

Kaikaia answered 14/6, 2019 at 19:42 Comment(0)
G
0

Had the same experience as OP, occurring for same reasons (Github's crypto removal notice of TlsV1, along with using a machine with a very old linux + git).

FWIW, if you find yourself on a very old version of linux, but you're stubbornly adamant you don't want to upgrade to a newer version of linux (hence instantly get a newer Git and all its deps), you could try build a newer Git, along with its dependencies from the source.

It's a time-consuming and painful path, and probably upgrading your linux is easier than this, but oh well, I just wanted to stick with my old linux.

I jotted a few notes of my attempt, hopefully it will help anyone that braves this path:

  • Git depended on openssl and curl, so I had to build those too
  • I had to upgrade my version of cmake in order to build the newer curl (building cmake took about 2-3 hours)
  • The newer cmake required me to build a newer gcc (which took about 21 hours to build on my old machine!)
  • Once I had cmake, I could build curl, but it referenced an older version of openssl (which did not have the newer TlsV1.2)
  • So I had to build a newer openssl, then followed by building curl (doing my utmost to assure the build referenced this newer openssl)
  • Then I could build Git, again, doing my best to assure it referenced the newer openssl and curl

I found myself repeatedly using "ldd" to confirm the referenced libraries, as on many occasions, the build would reference the wrong one, and I'd have to figure out how to enforce my desired path.

Some examples of this were:

# ldd /opt/git-2.27.0/libexec/git-core/git-http-fetch | grep -E "libssl|libcrypto|libcurl"
        libcurl.so => /usr/local/lib/libcurl.so (0x00aed000)
        libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00e86000)
        libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00893000)

This helped me confirm 'git-http-fetch" was making using of my newer curl (at /usr/local/lib, and not /usr/lib), and my newer openssl (at /usr/local/ssl/lib, and not /usr/lib)

$ ldd /usr/local/bin/curl | grep -E "libssl|libcrypto"
        libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00110000)
        libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x0016f000)

This helped me confirm that my new 'curl' was referencing newer openssl (at /usr/local/ssl/lib, and not /usr/lib)

To enforce these paths, Git let you set these env-vars prior to building:

OPENSSLDIR=/usr/local/ssl/
CURLDIR=/usr/local/

For curl, I had to pass the openssl path via cmake:

cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl .

For cmake, it also referenced openssl, and I passed that path across on its 'bootstrap' step:

./bootstrap --prefix=/opt/cmake-3.17.3 -- -DOPENSSL_ROOT_DIR=/usr/local/ssl

Apologies for the answer being all over the place. I can flesh it out with more detail if there is a request for it, but given that its taken me about a week to sort this out, I think most people will prefer the sane path of just upgrading your linux.

Gamester answered 1/7, 2020 at 13:25 Comment(1)
I would point out that many users are just that, users. They can only install stuff in their home directory. Hence, they need this kind of approach instead of upgrading the distro.Artilleryman

© 2022 - 2024 — McMap. All rights reserved.