cURL не работает (ошибка #77) для SSL-соединений на CentOS для некорневых пользователей
совсем недавно мой сервер перестал работать для запросов 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
может ли кто-нибудь пролить свет на то, почему это могло внезапно измениться, или еще лучше, как это исправить?
спасибо
5 ответов
если вы недавно достигли здесь, как я сделал при поиске той же ошибки напрасно, вы можете обнаружить, что это обновление для 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='
и то же самое здесь.
ошибка вызвана повреждением или отсутствием файлов сертификатов цепочки SSL в каталоге PKI. Вам нужно будет убедиться, что файлы ca-bundle, следующие шаги: В консоли / терминале:
mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates
введите этот сайт:https://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates, получите ваш ca-сертификат, для вас так, например: ftp://rpmfind.net/linux/fedora/linux/updates/24/x86_64/c/ca-certificates-2016.2.8-1.0.fc24.noarch.rpm
rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv
Теперь перезапустите службу: мой пример это команда:
sudo service2 httpd restart
очень большая хороший вид
я столкнулся с той же проблемой, когда пытался выполнить 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
заметил эту проблему, когда я неправильно настроил путь хранилища ключей. После исправления пути хранилища ключей он работал.