cURL SSL ошибка соединения 35 с ошибкой NSS -5961
У меня есть удаленный сервер Windows 7, который доступен только через HTTPS через порт 768. Сервер использует подписанный сертификат от CA, указанного в локальном сервере CentOS.
Всякий раз, когда я пытаюсь получить доступ к удаленному серверу через cURL, используя следующую команду, он выдает ошибку следующим образом:
[[email protected] certs]# curl -3 -v https://1.1.1.1:768/user/login
* About to connect() to 1.1.1.1 port 768 (#0)
* Trying 1.1.1.1... connected
* Connected to 1.1.1.1 (1.1.1.1) port 768 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
(Обратите внимание, что IP-адрес был скрыт по соображениям безопасности).
Я использую следующую версию cURL:
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Стоит отметить, что это работает на двух других удаленных серверах, которые работают под управлением Windows XP, а не Windows 7.
Я попытался заставить cURL использовать SSLv3 (используя флаг -3 и флаг -SSLv3), но безуспешно.
Я только что протестировал ту же команду CURL на Raspberry Pi с Raspbian и смог успешно подключиться. Поэтому я считаю, что это может быть проблема с версией cURL, используемой на сервере CentOS. Raspberry Pi работает под управлением следующей версии:
curl 7.26.0 (arm-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps Gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
curl с NSS считывает сертификаты корневого ЦС по умолчанию из "/etc/pki/tls/certs/ca-bundle.crt" в формате PEM.
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
Вы можете указать другой (ваш) сертификат CA (или пакет в NSS Shared DB ) с помощью опции curl --cacert с файлом PEM, содержащим сертификат (ы) CA.
Если вы не укажете сертификат вручную с параметром --cacert, NSS попытается автоматически выбрать правильный из базы данных NSS (расположенной в /etc/pki/nssdb). Вы можете указать его псевдоним с помощью параметра curl --cert, этого должно быть достаточно, если ключ встроен в сертификат, если нет, вы можете указать файл PEM с ключом сертификата, используя --key. Если ключ защищен парольной фразой, вы можете задать его с помощью параметра curl --pass, чтобы вы могли импортировать свой сертификат в общую базу данных NSS с помощью nss-tools (yum install nss-tools)
Добавление сертификата (общая командная строка)
certutil -d sql:/etc/pki/nssdb -A -t <TRUSTARGS> -n <certificate nickname> -i <certificate filename>
О TRUSTARGS
Укажите атрибуты доверия для изменения в существующем сертификате или для применения к сертификату при его создании или добавлении в базу данных.
Для каждого сертификата доступно три категории доверия выражается в следующем порядке: «SSL, электронная почта, подпись объекта». В каждом позиция категории использует ноль или более следующих кодов атрибутов:
- p запрещено (явно не доверяют)
- P Доверенный пэр
- c Действительный CA
- T Trusted CA для выдачи клиентских сертификатов (подразумевается c)
- C Trusted CA для выдачи сертификатов сервера (только SSL) (подразумевается c)
- сертификат может быть использован для аутентификации или подписи
- w Отправить предупреждение (используйте с другими атрибутами, чтобы включить предупреждение, когда сертификат используется в этом контексте)
Коды атрибутов для категорий разделяются запятыми и весь набор атрибутов заключен в кавычки. Например:
-т "Тку, Си, Ту"
Доверие сертификату корневого ЦС для выдачи сертификатов сервера SSL
certutil -d sql:/etc/pki/nssdb -A -t "C,," -n <certificate nickname> -i <certificate filename>
Импорт промежуточного сертификата CA
certutil -d sql:/etc/pki/nssdb -A -t ",," -n <certificate nickname> -i <certificate filename>
Доверие самоподписанному сертификату сервера
certutil -d sql:/etc/pki/nssdb -A -t "P,," -n <certificate nickname> -i <certificate filename>
Добавление личного сертификата и личного ключа для аутентификации клиента SSL
pk12util -d sql:/etc/pki/nssdb -i PKCS12_file_with_your_cert.p12
Перечисление всех сертификатов, хранящихся в БД NSS
certutil -d sql:/etc/pki/nssdb -L
Список деталей сертификата
certutil -d sql:/etc/pki/nssdb -L -n <certificate nickname>
Удаление сертификата
certutil -d sql:/etc/pki/nssdb -D -n <certificate nickname>
Надеюсь это поможет.
Я недавно столкнулся с той же проблемой в коробке CentOS 6. Оказалось, что сервер не обновлялся в течение достаточно долгого времени, а версия NSS была слишком старой. Исправлено обновлением curl и NSS:
yum update -y nss curl libcurl
Эта ошибка также выдается, когда сервер не поддерживает протокол ssl. Попробуйте указать все варианты/протоколы в файле server.xml.
Что происходит
Звучит так, как будто вы испытываете проблему тайм-аута при подключении к серверу Windows 7.
Возможные решения
Один из возможных answer указывает на основную причину ошибки 5961, которая оказалась проблемой настройки сетевого MTU. Непонятно, есть ли у вас доступ к серверу Windows 7 или всем компонентам среды, чтобы определить точную причину тайм-аута, из-за которого не удается установить соединение. Я бы проверил MTU сервера Windows 7 и сравнил настройки MTU с настройками других серверов. Если вы обнаружите, что вам нужно изменить настройки, вы можете следовать этой процедуре .
Это также произойдет, когда шифры между клиентом и сервером не перекрываются.
Например, сервер принимает только ECHDE-шифр, но клиент (в некоторых старых версиях curl, созданных с помощью nss) не имел этого шифра.
в этом случае сервер отправит TCP RST клиенту, чтобы прервать попытку соединения SSL, когда обнаружит, что ни один шифр не перекрывается (клиент включит поддерживаемый шифр в «hello клиента»).