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
Improve this question
7
  • Relevant: www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/… 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 2, 2016 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 2, 2016 at 13:02
  • 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 3, 2016 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 3, 2016 at 15:35
  • 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 4, 2016 at 18:34

3 Answers 3

Reset to default
8

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

Improve this answer
3
  • 14
    Upgrading the nss package (i.e. yum update nss) or using curl -1 might also solve this.
    – DiegoG
    Dec 14, 2016 at 12:31
  • 1
    Thanks! I encountered this problem because the server requires tlsv1.2. Upgrade did solve my problem.
    – hao
    Nov 23, 2017 at 9:12
  • updating the nss is to fix that issue
    – Sơn Lâm
    Mar 6, 2019 at 9:42
4

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

Improve this answer
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).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .