Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Starting today (or within the last few days) I've hit an SSL error when trying to connect to github.com (e.g. to clone a repository).

This is a legacy server running Red Hat 4.1.2-33.

Here's what it looks like when I try to connect:

$ curl https://www.github.com --verbose
* About to connect() to www.github.com port 443 (#0)
*   Trying 192.30.252.130... connected
* Connected to www.github.com (192.30.252.130) port 443 (#0)
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

I can see from this page that the NSS error code is:

"Cannot communicate securely with peer: no common encryption algorithm(s)."

The local and remote systems share no cipher suites in common. This can be due to a misconfiguration at either end. It can be due to a server being misconfigured to use a non-RSA certificate with the RSA key exchange algorithm.

If I'm putting this altogether right, it appears that github.com has a recently updated SSL certificate and my server doesn't have a cipher suite compatible with it. This is a legacy server so I'm not that surprised.

I've tried yum update nss (since that what curl seems to be using) as well as yum update openssl but none of those packages have updated.

I've also tried following the procedure outline here but to no avail.

I'm sort of hitting a wall with my knowledge of how TLS handshakes work to even troubleshoot this much deeper. Does anyone have any good ideas on how to start digging deeper and figuring out what's going wrong and where I need to update things? Upgrading the OS is for the time being not an option.

Update

Digging further, it appears to be an issue with libcurl and the cipher it is using when connecting to github.com via git. I can get curl to work if I specify a compatible cipher explicitly:

$ curl https://github.com --cipher rsa_aes_128_sha

And I can even add the --cipher rsa_aes_128_sha parameter to a .curlrc file and have curl use that cipher by default. Unfortunately, this doesn't seem to get picked up by the git command so it got me nowhere...nor could I find an alternate way to specify the cipher. This is what the result of a verbose git pull looks like on a github.com repository:

$ GIT_CURL_VERBOSE=1 git pull
* Couldn't find host github.com in the .netrc file, using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.129... * Connected to github.com (192.30.252.129) port 443 (#0)
*   CAfile: /root/certs/cacert.pem
  CApath: none
* NSS error -12286
* Expire cleared
* Closing connection #0
* Couldn't find host github.com in the .netrc file, using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.129... * Connected to github.com (192.30.252.129) port 443 (#0)
*   CAfile: /root/certs/cacert.pem
  CApath: none
* NSS error -12286
* Expire cleared
* Closing connection #0
error: SSL connect error while accessing https://github.com/twbs/bootstrap.git/info/refs
fatal: HTTP request failed

This might be a dead-end...looks like this guy on StackOverflow ran into the exact same issue.

share|improve this question
    
Just a note to those who using old soft without ability to updrage all system: it is enough to update next libs: libnss3.so, libssl3.so, libnssutil3.so (you can get it from xulrunner package) –  user1516873 Sep 26 at 11:13

2 Answers 2

SSL/TLS configuration today is driven by security considerations which have arisen in the past couple of years such as the BEAST and CRIME attacks, and the weakness of RC4, and which -- in some cases -- will result in some old clients being unable to communicate at all, since they don't support more modern protocols, cipher suites, etc. Even RHEL 5 clients occasionally have trouble communicating with RHEL 6 servers via SSL/TLS. With some work, you may be able to manually specify a cipher suite to use, but it's highly unlikely with something as old as RHEL4. This state of affairs makes upgrading your only real option.

share|improve this answer
    
Thanks. If you see my update, I was able to get curl to work by manually specifying a cipher, but unable to find a way to get the git command to that cipher when calling curl. –  Jim D Jan 2 at 22:26

... before you're going spend time hitting wall and all) check your date/time:

[alexus@wcmisdlin02 ~]$ sudo ntpdate time.apple.com
 2 Jan 16:33:44 ntpdate[6883]: adjust time server 17.171.4.35 offset 0.000416 sec
[alexus@wcmisdlin02 ~]$ 

this may not be your issue, but i've had issues when time wasn't right, SSL didn't work for me.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.