をNSS error -12286使用してHTTPSからファイルをダウンロード中にエラーが発生しますcurl。
を使用しwgetて問題なく同じファイルをダウンロードできるため、ファイアウォールやブラックリストの問題を除外できます。
すでに試してみましたが、運が悪く、オプションが-kあり--cipher ecdhe_ecdsa_aes_128_gcm_sha_256、これはQualys SSL Labs Test Serverツールによるサーバー優先暗号です：https ://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net &latest
ここにcURLログがあります：
# 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
私のlibバージョンは次のとおりです。
# 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
CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7の問題をテストサーバーに再現できます。デフォルトでは、ECCスイートは提供されていません。サーバー（Cloudfare）は特定のECC（特にECDHE）スイートのみを受け入れるため、ネゴシエーションは失敗します。
—
dave_thompson_085 2016年
--cipher[s]そのECDHEスイートを指定して、それだけでも、接続を閉じて、エラーが発生します、のClientHelloを送信しません。これは、おそらくRedHatによる長いECCの拒否の後に、内部的に同期されていないようです。RedHat wgetはOpenSSLを使用し、最近のRedHat OpenSSLはECCをサポートしています（P256 P384 P521でのみですが、ここではそれで十分です）。
私の最初の選択は（0）（これ）カールを使用しないことですが、私が見るオプションが本当に必要な場合は、次のとおりです。（2）オープンソースです。自分でデバッグして修正します。（3）オープンソースです。機能するはずのopenssl（NSSの代わりに）に対して再構築します。（4）
—
dave_thompson_085 2016年
stunnel（opensslを使用する）をプレーンからSSLに設定し、curlに通知しますが、ターゲットサーバーが違いを認識できないようにhttp(notS)://localhost[:port]/whatever追加し-H "Host: realhost"ます。...
...（5）似ているがより公式：ここでopensslを使用して実際のHTTPプロキシをセットアップするか、制御内の別のシステムにTLS1.2-ECDHE互換のSSL / TLSを設定します。HAproxyなどの実際のマシンのVMまたはnginxまたはhttpdであり、プレーンHTTPまたは少なくとも非ECDHE HTTPSで接続しますが、適切なECDHE HTTPSで実サーバーにリレーします。
—
dave_thompson_085 2016年
NSSアップストリームは間違いなくECDHEを長期間サポートします。RedHatは2014年後半まで何年にもわたって、あいまいな「法的」理由のために暗号パッケージ（AFAIKすべて、間違いなくOpenSSL NSS OpenJDK）のビルドから（すべてのバリアントの）ECCを削除しました。彼らがそれを元に戻したとき、私はこのカール/ NSSのケースに影響を与えるいくつかのおそらくマイナーなミスをしたと思います。これを行った他のディストリビューションは知りませんが、たくさんあります。私が現在持っている1つのUbuntu 14.04LTS Trustyでは、curlはOpenSSLを使用し、ECDHEをサポートしています。
—
dave_thompson_085 2016年
SSL_ERROR_NO_CYPHER_OVERLAP「ピアと安全に通信できない：共通の暗号化アルゴリズムがない」ことを意味していると記載されています ローカルシステムとリモートシステムは、共通の暗号スイートを共有していません。これは、両端の設定ミスが原因である可能性があります。これは、RSA鍵交換アルゴリズムで非RSA証明書を使用するようにサーバーが誤って構成されていることが原因である可能性があります。