cURL не работает (Ошибка № 77) для SSL-соединений в CentOS для пользователей без полномочий root
Совсем недавно мой сервер перестал работать для запросов 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, то, в зависимости от дистрибутива ОС, возможно, потребуется предпринять некоторые дополнительные шаги для использования общесистемного сертификата CA db. RedHat поставляется с дополнительным модулем, libnsspem.so, который позволяет NSS Прочитайте пакет OpenSSL PEM CA. Эта библиотека отсутствует в OpenSuSE, и без него NSS может работать только со своими собственными внутренними форматами. NSS также имеет новый формат базы данных: https://wiki.mozilla.org/NSS_Shared_DB"
... но я не могу найти информацию о том, как я могу получить эту работу всей системы на моем сервере CentOS.
Информация
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
Может кто-нибудь пролить свет на то, почему это могло внезапно измениться, или, что еще лучше, как это исправить?
Спасибо
12 ответов
Оказывается, проблема была в том, что скрипт запускался из cPanel "электронная почта, отправляемая в сценарий", поэтому работал как пользователь, так что это была проблема пользователя, но никак не влияла на веб-сервер.
Причина, по которой пользователь не смог получить доступ к каталогу /etc/pki, была вызвана тем, что у него был только ssh-доступ в тюрьму. Как только я предоставил полный доступ, все заработало нормально.
Спасибо за информацию, хотя, Реми.
У меня просто была похожая проблема с ошибкой № 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, чтобы их можно было добавить заново.
Если вы недавно пришли сюда, как и я, при поиске той же ошибки напрасно, вы можете обнаружить, что это обновление 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Я начал читать о проверке сертификатов с помощью 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
Попробуй еще раз и удачи!
For Ubuntu:
sudo apt-get install ca-certificates
Hit this problem trying to curl things as ROOT inside of Dockerfile
У меня была такая же проблема с CentOS-7. На меня это подействовало.
Создание пустого файла.
touch /etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned
В дистрибутивном образе CentOS-7 была ошибка curl.
Убедитесь, что у вас установлены правильные права на пакет сертификатов CA. Обычно это означает, что доступ для всех к файлам CA в каталоге / etc / ssl / certs, например, /etc/ssl/certs/ca-certificates.crt, доступен для чтения всем.
Вы можете увидеть, какие файлы были настроены для вас версия curl с
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='
И то же самое здесь.
Я сталкивался с той же проблемой всякий раз, когда пытался выполнить 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
Заметил эту проблему, когда я неправильно настроил путь хранилища ключей. После исправления пути хранилища ключей все заработало.
Ошибка php-curl №77 не позволяла нашим платежным шлюзам работать на нашем сайте magento.
Эта ошибка № 77 связана с сертификатом, однако нам никогда не приходилось настраивать сертификат, чтобы это работало. И ошибка началась внезапно и затронула каждого клиента.
После того, как мы попробовали многие решения, перечисленные здесь и в других местах, нам ничего не помогло.
Многие люди предлагали перезапустить службу httpd, но оказалось, что для нас решением, о котором я нигде не упоминал, был перезапуск службы php.
sudo systemctl restart php-fpm
Надеюсь, это поможет вам!
для меня это исправлено подсказкой @DavidG выше. И практически я бегу:
ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/pki/tls/certs/ca-bundle.crt
Исправлено после этого!
Проверьте разрешения для сертификатов CA, установленных на сервере.
Ошибка связана с повреждением или отсутствием файлов сертификата цепочки SSL в каталоге PKI. Вам нужно убедиться, что файлы в комплекте, выполните следующие действия: В вашей консоли / терминале:
mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates
Зайдите на этот сайт: https://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates, получите свой CA-сертификат для своего 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 сейчас, установите свой rpm:
rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv
Теперь перезапустите ваш сервис: мой пример этой команды:
sudo service2 httpd restart
очень здорово хорошо выглядеть
Пользователи Windows, добавьте это в PHP.ini:
curl.cainfo = "C:/cacert.pem";
Путь необходимо изменить на свой, и вы можете скачать cacert.pem из поиска Google
(да, я знаю, что это вопрос CentOS)