CURL Ошибка подключения SSL 35 с ошибкой NSS -5961

У меня есть удаленный сервер Windows 7, доступный только через HTTPS на порту 768. Сервер использует подписанный сертификат из ЦС, указанного на локальном сервере 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. Малина 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

ОТВЕТЫ

Ответ 1

curl, когда NSS читает сертификаты Root 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 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, электронная почта, подписка на объект". В каждом категория position использует ноль или более следующих кодов атрибутов:

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

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

-t "TCu, Cu, Tuw"

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

Надеюсь, что это поможет.

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

Недавно я столкнулся с той же проблемой в окне CentOS 6. Оказалось, что сервер не обновлялся довольно долго, а версия NSS была слишком старой. Исправлено обновлением как curl, так и NSS:

yum update -y nss curl libcurl

Ответ 5

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

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

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