Saya mendapatkan kesalahan NSS error -12286saat mengunduh file dari HTTPS menggunakan curl.
Saya dapat mengunduh file yang sama tanpa masalah menggunakan wgetsehingga saya dapat mengecualikan masalah firewall atau daftar hitam.
Sudah mencoba, tanpa keberuntungan, opsi -kdan --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, itulah cipher yang disukai server menurut alat Qualys SSL Labs Test Server di sini: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest
Ini cURLlognya:
# 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
Versi lib saya adalah:
# 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
Saya dapat mereproduksi masalah Anda dengan CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 ke server uji. Secara default ia tidak menawarkan suite ECC, dan karena server Anda (Cloudfare) hanya menerima negotasi ECC (khususnya ECDHE) gagal. Dengan
—
dave_thompson_085
--cipher[s]menentukan suite ECDHE, itu bahkan tidak mengirim ClientHello, cukup tutup koneksi dan berikan kesalahan. Ini tampaknya menjadi sesuatu yang tidak sinkron secara internal, mungkin setelah penolakan panjang RedHat terhadap ECC. RedHat wget menggunakan OpenSSL, dan RedHat OpenSSL baru-baru ini mendukung ECC (hanya dengan P256 P384 P521 tapi itu sudah cukup di sini).
Pilihan pertama saya adalah (0) jangan menggunakan ikal (ini), tetapi jika Anda benar-benar menginginkan opsi yang saya lihat adalah: (1) jika Anda memiliki dukungan, laporkan sebagai bug dan berharap mereka memperbaikinya. (2) ini open source; debug dan perbaiki sendiri. (3) ini open source; membangun kembali terhadap openssl (bukan NSS) yang seharusnya berfungsi. (4) mengatur
—
dave_thompson_085
stunnel(yang menggunakan openssl) sebagai plain-to-SSL, beri tahu curl http(notS)://localhost[:port]/whatevertetapi tambahkan -H "Host: realhost"sehingga server target tidak dapat membedakannya. ...
... (5) serupa tetapi lebih resmi: mengatur proxy HTTP nyata menggunakan openssl di sini, atau SSL / TLS yang kompatibel dengan TLS1.2-ECDHE di sistem lain dalam kendali Anda, mungkin bahkan VM di mesin Anda yang sebenarnya, seperti HAproxy atau nginx atau bahkan httpd, yang Anda sambungkan dengan HTTP biasa atau setidaknya HTTPS non-ECDHE tetapi relay ke server nyata dengan HTTPS ECDHE yang baik.
—
dave_thompson_085
NSS hulu pasti mendukung ECDHE untuk waktu yang lama. RedHat selama bertahun-tahun hingga akhir 2014 menghapus (semua varian) ECC dari paket crypto mereka (AFAIK semua, pasti OpenSSL NSS OpenJDK) karena alasan 'hukum' yang samar, yang di atas saya sebut 'penolakan panjang'. Saya menduga ketika mereka mengembalikannya mereka membuat beberapa kesalahan kecil yang mungkin mempengaruhi kasus curl / NSS ini. Saya tidak tahu distro lain yang melakukan ini, tetapi ada banyak dan seseorang mungkin; dalam Ubuntu yang saat ini saya miliki, 14.04LTS Trusty, curl menggunakan OpenSSL dan mendukung ECDHE.
—
dave_thompson_085
SSL_ERROR_NO_CYPHER_OVERLAP"Tidak dapat berkomunikasi dengan aman dengan rekan: tidak ada algoritma enkripsi umum." Sistem lokal dan jarak jauh tidak memiliki cipher suite yang sama. Ini bisa disebabkan oleh kesalahan konfigurasi di kedua ujungnya. Ini bisa disebabkan oleh server yang salah konfigurasi untuk menggunakan sertifikat non-RSA dengan algoritma pertukaran kunci RSA.