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, когда обнаружит, что не перекрывается шифрование (клиент будет включать поддерживаемый шифр в "приветствие клиента" ).
