Nss error 5961

у меня есть удаленный сервер Windows 7, который доступен только через HTTPS на порту 768. Сервер использует подписанный сертификат из центра сертификации, указанного на локальном сервере CentOS.

всякий раз, когда я пытаюсь получить доступ к удаленному серверу через cURL с помощью следующей команды, он выдает следующие ошибки:

[usr@serv 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. Малина 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 прочитайте корневые сертификаты CA по умолчанию из "/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 общая БД) по варианту curl --cacert с файлом PEM, содержащим сертификат(ы) CA.

если вы не укажете сертификат вручную с помощью --cacert опция, NSS пытается выбрать правильный из базы данных NSS (находится в /etc/pki/nssdb) автоматически. Вы можете укажите его ник с помощью опции curl --cert, этого должно быть достаточно, если ключ встроен в сертификат, если нет, вы можете указать файл PEM с ключом сертификата, используя --key. Если ключ защищен парольной фразой, вы можете дать его опцией curl --pass таким образом, вы можете импортировать свой сертификат в общую БД NSS с помощью НСС-инструменты (yum install nss-tools)

добавление сертификата (общая команда line)

certutil -d sql:/etc/pki/nssdb -A -t <TRUSTARGS> -n <certificate nickname> -i <certificate filename>

о TRUSTARGS

укажите атрибуты доверия, которые необходимо изменить в существующем сертификате или применить к сертификату при его создании или добавлении в базу данных.

существует три категории доверия для каждого сертификата,
выражается в таком порядке: «SSL, email, подпись объекта». В каждом
позиция категории используйте ноль или более следующих кодов атрибутов:

• p запрещено (явно не доверяют)
• P доверенный peer
• C действительный CA
• T доверенный CA для выдачи сертификатов клиента (подразумевает c)
• C доверенный CA для выдачи сертификатов сервера (только SSL) (подразумевает c)
• сертификат у можно использовать для удостоверения подлинности или подписания
• w отправить предупреждение (используйте с другими атрибутами, чтобы включить предупреждение, когда сертификат используется в этом контексте)

коды атрибутов для категорий, разделенных запятыми, и
весь набор атрибутов, заключенный в кавычки. Например:

— t «TCu, Cu, Tuw»

доверие корневому сертификату CA для выдачи сертификатов сервера 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 DB

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

что происходит

Это звучит так, как будто вы испытываете проблему тайм-аута при подключении к серверу Windows 7.

Возможные Решения

один из возможных ответ указывает на первопричину ошибки 5961 оказалась проблема настройки MTU сети. Неясно, есть ли у вас доступ к серверу Windows 7 или полным компонентам среды, чтобы определить точную причину тайм-аута это приводит к сбою соединения. Я бы проверил MTU сервера Windows 7 и сравнил настройку MTU с настройкой других серверов. Если вы обнаружите, что вам нужно изменить настройки, вы можете следовать этому процедура.

эта ошибка также выдается, когда протокол ssl не поддерживается сервером, попробуйте указать все варианты / протоколы на сервере.XML-файл.

Это произойдет, когда шифры между клиентом и сервером не перекрываются.

например, сервер принимает только шифр ECHDE, но клиент (некоторая старая версия curl, построенная с nss) не имел этого шифра.

в этом случае сервер сначала отправит TCP клиенту для завершения попытки подключения SSL, когда он обнаружит, что шифр не перекрывается (клиент будет включать поддерживаемый шифр в «клиент hello»).