CURL не работает (ошибка № 77) для SSL-соединений в CentOS для пользователей без полномочий root

Ответ 1

Оказывается, проблема заключалась в том, что проблема с script выполнялась с помощью cPanel "email, отправленного по адресу script", поэтому работала как пользователь, так что это была проблема с пользователем, но не влияла на Интернет сервера вообще.

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

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

Ответ 2

Если вы недавно пришли сюда, как и я, при поиске той же ошибки напрасно, вы можете обнаружить, что это обновление NSS, вызывающее сбой в CentOS. Протестируйте, запустив yum update, и посмотрите, есть ли ошибки, 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 проблема: 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 и о том, как это новое обновление может быть связано с моими проблемами. Итак, ням сломан. Это потому, что nss-softokn- * нужен nss-softokn-freebl- * нужен друг другу для работы. Проблема в том, что они не проверяют версию друг друга на совместимость, и в некоторых случаях это приводит к поломке ням. Давайте исправим вещи:

$ 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

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

Чтобы исправить ситуацию с WordPress вам нужно перезагрузить ваш http-сервер.

$ service httpd restart

Попробуй еще раз и удачи!

Ответ 3

У меня просто была похожая проблема с ошибкой № 77 на CentOS7. Мне не хватало мягкой ссылки /etc/pki/tls/certs/ca-bundle.crt, которая установлена с RP -сертификатом ca-Certificates.

'curl' пытался открыть этот путь, чтобы получить Центры сертификации. Я обнаружил с помощью:

strace curl https://example.com

и ясно увидел, что открывать не удалось по этой ссылке.

Мое исправление было:

yum reinstall ca-certificates

Это должно настроить все снова. Если у вас есть частные CA для корпоративного или самозаверяющего использования, убедитесь, что они находятся в /etc/pki/ca-trust/source/anchors, чтобы их можно было добавить заново.

Ответ 4

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

Вы можете увидеть, какие файлы были настроены для вашей версии с помощью команды

curl-config --configure

$ 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 -certificates.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='

И тут же.

Ответ 5

Для Ubuntu:

sudo apt-get install ca-certificates

Хит эту проблему, пытаясь свернуть вещи как корень внутри Dockerfile

Ответ 6

Ошибка связана с повреждением или отсутствием файлов сертификатов цепочки 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-сертификат, например yout SO: ftp://rpmfind.net/linux/fedora/linux/updates/24/x86_64/c/ca-certificates-2016.2.8-1.0.fc24.noarch.rpm < < CentOS. Скопируйте URL-адрес для загрузки и вставки URL-адреса:   wget your_url_donwload_ca-ceritificated.rpm теперь установите yout rpm:

rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv

теперь перезапустите службу: мой пример этой команды:

sudo service2 httpd restart

очень здорово хороший внешний вид

Ответ 7

Я сталкивался с той же проблемой всякий раз, когда пытался выполнить 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

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

Ответ 8

Пользователи Windows, добавьте это в PHP.ini:

curl.cainfo = "C:/cacert.pem";

Путь нужно изменить на свой, и вы можете скачать cacert.pem из поиска Google

(да, я знаю, это вопрос CentOS)