9

I'm getting error NSS error -12286 while downloading a file from HTTPS using curl.

I can download the same file without issues using wget so I can exclude any firewall or blacklist issues.

Already tried, with no luck, options -k and --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, that is the server preferred cipher according to Qualys SSL Labs Test Server tool here: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest

Here is the cURL log:

# curl -v https://www.intribunale.net/immobili
* About to connect() to www.intribunale.net port 443 (#0)
*   Trying 104.27.150.214... connected
* Connected to www.intribunale.net (104.27.150.214) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

My lib versions are:

# curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Marco Marsala
  • 353
  • 1
  • 4
  • 14
  • Relevant: http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html where it says that NSS error -12286 means `SSL_ERROR_NO_CYPHER_OVERLAP` "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. – Celada May 02 '16 at 12:26
  • 2
    I can reproduce your problem with CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 to a test server. By default it doesn't offer any ECC suites, and since your server (Cloudfare) accepts *only* certain ECC (specifically ECDHE) suites negotation fails. With `--cipher[s]` specifying that ECDHE suite, it doesn't even send ClientHello, just closes the connection and gives the error. This appears to be something out of sync internally, perhaps after RedHat's long denial of ECC. RedHat wget uses OpenSSL, and recent RedHat OpenSSL does support ECC (only with P256 P384 P521 but that's enough here). – dave_thompson_085 May 02 '16 at 13:02
  • @dave_thompson_085 How I can solve the issue? I have full control of the CentOS server, but intribunale.net is not under my control (it is a site I'm trying to connect to). – Marco Marsala May 02 '16 at 13:57
  • 1
    My first choice would be (0) don't use (this) curl, but if you really want the options I see are: (1) if you have support, report it as a bug and hope they fix it. (2) it's open source; debug and fix it yourself. (3) it's open source; re-build against openssl (instead of NSS) which should work. (4) set up `stunnel` (which uses openssl) as plain-to-SSL, tell curl `http(notS)://localhost[:port]/whatever` but add `-H "Host: realhost"` so the target server can't tell the difference. ... – dave_thompson_085 May 03 '16 at 15:31
  • 1
    ... (5) similar but more official: set up a real HTTP proxy using openssl here, or any TLS1.2-ECDHE-compatible SSL/TLS on another system in your control maybe even a VM on your real machine, like HAproxy or nginx or even httpd, that you connect to with plain HTTP or at least non-ECDHE HTTPS but relays to the real server with good ECDHE HTTPS. – dave_thompson_085 May 03 '16 at 15:35
  • @dave_thompson_085 Wow so many things I learned from your post. A curiosity, cURL with NSS works in other distros (e.g. Ubuntu)? Or the latest available NSS version still not support ECDHE? – Marco Marsala May 03 '16 at 16:54
  • 1
    NSS upstream definitely supports ECDHE for a long time. RedHat for years until late 2014 *removed* (all variants of) ECC from their builds of crypto packages (AFAIK all, definitely OpenSSL NSS OpenJDK) for vague 'legal' reasons, which above I called 'long denial'. I'm guessing when they put it back they made some probably-minor mistake affecting this curl/NSS case. I don't know any other distro that did this, but there are many and someone might; in the one Ubuntu I currently have, 14.04LTS Trusty, curl uses OpenSSL and does support ECDHE. – dave_thompson_085 May 04 '16 at 18:34

3 Answers3

8

The solution was upgrading to cURL 7.42 using a third party repository for CentOS 6 or building from sources

Marco Marsala
  • 353
  • 1
  • 4
  • 14
4

We had same issue with curl 7.19.7. We upgraded NSS and it fixed the issue!

Jacob Klein
  • 41
  • 1
0

On CentOS 6 with latest openssl package (1.0.1e) You should update nss (yum update nss) as DiegoG wrote above. Command update-ca-trust also can be helpful. If You are using curl via php - restart you webserver process/service (i.e. service httpd restart).

userK
  • 1
  • 1