Я получаю сообщение об ошибке 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
--cipher[s]указании этого ECDHE пакет, он не даже отправить ClientHello, просто закрывает соединение и выдает ошибку. Похоже, это что-то не синхронизировано внутри, возможно, после долгого отказа RedHat от ECC. RedHat wget использует OpenSSL, а недавний RedHat OpenSSL поддерживает ECC (только с P256, P384, P521, но этого здесь достаточно).
Мой первый выбор: (0) не использовать (это) curl, но если вы действительно хотите, чтобы варианты, которые я вижу, были: (1) если у вас есть поддержка, сообщите об этом как об ошибке и надеемся, что они исправят ее. (2) это открытый исходный код; отладить и исправить это самостоятельно. (3) это открытый исходный код; пересобрать против openssl (вместо NSS), который должен работать. (4) настроить
—
dave_thompson_085
stunnel(который использует openssl) как обычный-SSL, сказать curl, http(notS)://localhost[:port]/whateverно добавить, -H "Host: realhost"чтобы целевой сервер не мог различить разницу. ...
... (5) аналогично, но более официально: настройте настоящий HTTP-прокси, используя openssl здесь, или любой TLS1.2-ECDHE-совместимый SSL / TLS в другой системе под вашим контролем, возможно, даже в виртуальной машине на вашей реальной машине, такой как HAproxy или nginx или даже httpd, к которому вы подключаетесь с помощью простого HTTP или, по крайней мере, не-ECDHE HTTPS, но пересылаете на реальный сервер с хорошими ECDHE HTTPS.
—
dave_thompson_085
NSS upstream определенно поддерживает ECDHE в течение длительного времени. RedHat в течение многих лет до конца 2014 года удалял (все варианты) ECC из своих сборок криптопакетов (AFAIK all, определенно OpenSSL NSS OpenJDK) по смутным «юридическим» причинам, которые выше я назвал «длинным отказом». Я предполагаю, что когда они вернули его обратно, они допустили небольшую, вероятно, незначительную ошибку, повлиявшую на этот случай скручивания / NSS. Я не знаю ни одного другого дистрибутива, который бы делал это, но есть много, и кто-то может; в одном Ubuntu, который у меня есть, 14.04LTS Trusty, curl использует OpenSSL и поддерживает ECDHE.
—
dave_thompson_085
SSL_ERROR_NO_CYPHER_OVERLAP«Невозможно безопасно связаться с одноранговым узлом : нет общего алгоритма (-ов) шифрования». Локальные и удаленные системы не имеют общих наборов шифров. Это может быть связано с неправильной настройкой на любом конце. Это может быть связано с неправильной настройкой сервера для использования сертификата не-RSA с алгоритмом обмена ключами RSA.