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 connected
* Connected to www.intribunale.net ( 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
  • 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 '16 at 12:26
  • 1
    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 '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 2 '16 at 13:57
  • 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 '16 at 15:31
  • 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 '16 at 18:34
up vote 4 down vote accepted

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

  • 5
    Upgrading the nss package (i.e. yum update nss) or using curl -1 might also solve this. – DiegoG Dec 14 '16 at 12:31
  • 1
    Thanks! I encountered this problem because the server requires tlsv1.2. Upgrade did solve my problem. – hao Nov 23 '17 at 9:12

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

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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