Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!
I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull
, push
, fetch
, etc. all work just fine.
After some amount of time(*), this stops, and I get the following error:
fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443
(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.
Checking via cURL, I get
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to github.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to github.com:443
Using set GIT_CURL_VERBOSE=1
with git pull
shows similar information. Sometimes it succeeds (see below), but most of the time it fails.
There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.
A successful cURL request looks like:
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS handshake, Server hello (2):
* TLSv1.0, TLS handshake, CERT (11):
* TLSv1.0, TLS handshake, Server finished (14):
* TLSv1.0, TLS handshake, Client key exchange (16):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* Server certificate:
* subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: 2014-04-08 00:00:00 GMT
* expire date: 2016-04-12 12:00:00 GMT
* subjectAltName: github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
> GET /our-team/private-repo.git/ HTTP/1.1
> User-Agent: curl/7.41.0
> Host: github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Mon, 11 May 2015 15:19:43 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://github.com/our-team/private-repo/
< Vary: Accept-Encoding
< X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host github.com left intact
I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).
What might be causing this failure, and how can I resolve it?
λ git --version
git version 1.9.5.msysgit.1
λ curl --version
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.
Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.
We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.
I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With