Nss error 5978

совсем недавно мой сервер перестал работать для запросов curl на https: / / адреса для моего веб-сервера. Покопавшись немного, кажется, что это проблема с пользователем, на котором работает веб-сервер.

если я SSH на сервер как root & call

curl -I -v https://google.com

… Я получаю следующий ответ…

* About to connect() to google.com port 443 (#0)
*   Trying 173.194.67.113... connected
* Connected to google.com (173.194.67.113) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
*       subject: CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US
*       start date: May 22 15:50:20 2013 GMT
*       expire date: Oct 31 23:59:59 2013 GMT
*       common name: *.google.com
*       issuer: CN=Google Internet Authority,O=Google Inc,C=US
> HEAD / HTTP/1.1
> User-Agent: 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
> Host: google.com
> Accept: */*

однако, если я вхожу в систему как любая из учетных записей cPanel (также используется при работе через веб-сервер), я получаю следующий…

* About to connect() to google.com port 443 (#0)
*   Trying 173.194.67.101... connected
* Connected to google.com (173.194.67.101) port 443 (#0)
* Initializing NSS with certpath: none
* NSS error -5978
* Closing connection #0
* Problem with the SSL CA cert (path? access rights?)
curl: (77) Problem with the SSL CA cert (path? access rights?)

Я не смог найти окончательного ответа на эту проблему, и моя хостинговая компания отказывается помочь, поскольку она «не поддерживает», хотя на прошлой неделе она работала нормально!

Я нашел упоминание о http://curl.haxx.se/docs/sslcerts.html это

» если libcurl был построен с поддержкой NSS, то в зависимости от дистрибутива ОС,
вероятно, необходимо предпринять некоторые дополнительные шаги для использования системы сертификации
cert db. RedHat поставляется с дополнительным модулем libnsspem.Итак, что позволяет
NSS для чтения пакета OpenSSL PEM CA. Эта библиотека отсутствует в OpenSuSE, и
без него NSS может работать только со своими собственными внутренними форматами. NSS также имеет новый
формат базы данных:https://wiki.mozilla.org/NSS_Shared_DB»

… но я не могу найти информацию о том, как я получить эту работу на моем CentOS в сервер.

Info

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
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

может ли кто-нибудь пролить свет на то, почему это могло внезапно измениться, или еще лучше, как это исправить?

спасибо

если вы недавно достигли здесь, как я сделал при поиске той же ошибки напрасно, вы можете обнаружить, что это обновление для NSS вызывает сбой на CentOS. Проверьте, запустив обновление yum и посмотрите, получаете ли вы ошибки, curl также создает эту ошибку. Решение достаточно простое, просто установите NSS вручную.

Читать далее…

если вы похожи на меня, он выбросил ошибку, похожую на эту:

curl: (77) Problem with the SSL CA cert (path? access rights?)

это заняло некоторое время, чтобы решить, но обнаружил, что это не сертификат CA, потому что воссоздавая их и проверяя всю конфигурацию, я исключил это. Это мог быть libcurl, поэтому я пошел искать обновления.

как упоминалось, я воссоздал сертификаты CA. Вы также можете это сделать, но это может быть пустой тратой времени. http://wiki.centos.org/HowTos/Https

следующий шаг (вероятно, должен был быть моим первым), чтобы проверить, что все было в курсе, просто запустив yum.

$ yum update
$ yum upgrade

Это дало мне утвердительный ответ, что есть большая проблема в игре:
Downloading Packages:
error: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
Problem opening package nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm
Я начал читать о проверке сертификатов с NSS и о том, как это новое обновление может быть связано с моими проблемами.
Итак, ням сломан. Это потому, что НСС-softokn-* должен НСС-softokn-freebl-* нужны друг другу, чтобы функционировать. Проблема в том, что они не проверяют друг друга на совместимость, и в некоторых случаях это заканчивается разрывом yum.
Пойдем исправим вещи:

$ wget http://mirrors.linode.com/centos/6.6/updates/x86_64/Packages/nsssoftokn-freebl-3.14.3-19.el6_6.x86_64.rpm
$ rpm -Uvh nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm
$ yum update

вы должны, конечно, скачать с ближайшего зеркала и проверить правильность версия / OS etc. Мы в основном загружаем и устанавливаем обновление с rpm, чтобы исправить yum. Как отметил @grumpysysadmin, вы можете сократить команды вниз. @cwgtex сообщил, что вы должны установить обновление с помощью команды RPM, что делает процесс еще проще.

чтобы исправить ситуацию с wordpress, вам нужно перезагрузить http-сервер.

$ service httpd restart

попробуйте еще раз и успех!

оказывается, проблема заключалась в том, что скрипт запускался из cPanel «email piped to script», поэтому работал как пользователь, так что это была проблема пользователя, но не влиял на веб-сервер вообще.

причина, по которой пользователь не может получить доступ к каталогу /etc/pki, заключалась в том, что они только заключили в тюрьму ssh-доступ. Как только я предоставил полный доступ, все сработало отлично.

Спасибо за информацию, Реми.

убедитесь, что у вас установлены правильные права на пакет сертификатов CA.
Обычно это означает доступ для чтения всех файлов CA в каталоге /etc/ssl/certs, например /etc/ssl/certs/ca-certificates.ЭЛТ.

вы можете увидеть, какие файлы были настроены для вас curl версии с

:

$ curl-config --configure
 '--prefix=/usr' 
 '--mandir=/usr/share/man' 
 '--disable-dependency-tracking' 
 '--disable-ldap' 
 '--disable-ldaps' 
 '--enable-ipv6' 
 '--enable-manual' 
 '--enable-versioned-symbols' 
 '--enable-threaded-resolver' 
 '--without-libidn' 
 '--with-random=/dev/urandom' 
 '--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt' 
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro' 
 'CPPFLAGS=-D_FORTIFY_SOURCE=2'

здесь вам нужен доступ для чтения к/etc/ssl/certs / ca-сертификатам.crt

$ curl-config --configure
 '--build' 'i486-linux-gnu' 
 '--prefix=/usr' 
 '--mandir=/usr/share/man' 
 '--disable-dependency-tracking' 
 '--enable-ipv6' 
 '--with-lber-lib=lber' 
 '--enable-manual' 
 '--enable-versioned-symbols' 
 '--with-gssapi=/usr' 
 '--with-ca-path=/etc/ssl/certs' 
 'build_alias=i486-linux-gnu' 
 'CFLAGS=-g -O2' 
 'LDFLAGS=' 
 'CPPFLAGS='

и то же самое здесь.

0

автор: Santos L. Victor

я столкнулся с той же проблемой, когда пытался выполнить curl на моем https-сервере.

About to connect() to localhost port 443 (#0)
Trying ::1...
Connected to localhost (::1) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb

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