对于非 root 用户在 CentOS 上的 SSL 连接 cURL 不起作用(错误 #77) [英] cURL not working (Error #77) for SSL connections on CentOS for non-root users
问题描述
就在最近，我的服务器已停止处理对我的 Web 服务器的 https://地址的 curl 请求.经过一番挖掘，似乎是网络服务器正在运行的用户存在问题.
Just recently my server has stopped working for curl requests to https:// addresses for my web server. Having dug around a little it appears that it's a problem with the user the webserver is running.
如果我以 root & 身份 SSH 到服务器打电话
If I SSH onto the server as root & call
curl -I -v https://google.com
...我收到以下响应...
... I get the following response...
* 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 帐户(也用于通过 Web 服务器运行时)登录，我会得到以下信息...
However, if I log in as any of the cPanel accounts (also used when running via the web server) I get the following...
* 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?)
我无法找到问题的明确答案，&我的托管公司拒绝提供帮助，因为它失去支持"，尽管上周运行良好！
I've not been able to find a definitive answer to the problem, & my hosting company are refusing to help as it's "Out of support" even though it was working fine last week!
我确实在 http://curl.haxx.se/docs/sslcerts.html 上发现提到
I did find mention on http://curl.haxx.se/docs/sslcerts.html that
"如果 libcurl 是在 NSS 支持下构建的，那么取决于操作系统发行版，可能需要采取一些额外的步骤来使用系统范围的 CA证书数据库.RedHat 附带了一个附加模块 libnsspem.so，它可以启用NSS 读取 OpenSSL PEM CA 包.OpenSuSE 中缺少该库，并且没有它，NSS 只能使用它自己的内部格式.NSS 也有一个新的数据库格式:https://wiki.mozilla.org/NSS_Shared_DB"
"If libcurl was built with NSS support, then depending on the OS distribution, it is probably required to take some additional steps to use the system-wide CA cert db. RedHat ships with an additional module, libnsspem.so, which enables NSS to read the OpenSSL PEM CA bundle. This library is missing in OpenSuSE, and without it, NSS can only work with its own internal formats. NSS also has a new database format: https://wiki.mozilla.org/NSS_Shared_DB"
...但我找不到有关如何在我的 CentOS 服务器上获得此工作系统范围的信息.
... but I can find no information on how I get this working system-wide on my CentOS server.
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
谁能解释一下为什么这可能会突然改变，或者更好的是如何解决它?
Can anyone shed some light on why this might have suddenly changed, or better still how to fix it?
谢谢
推荐答案
原来问题出在面子上，脚本是从 cPanel email piped to script"运行的，所以是以用户身份运行的，所以是用户问题，但完全没有影响 Web 服务器.
Turns out that the problem was with face that the script was running from a cPanel "email piped to script", so was running as the user, so is was a user problem, but was not affecting the web server at all.
用户无法访问/etc/pki 目录的原因是他们只有被监禁的 ssh 访问权限.一旦我授予完全访问权限，一切正常.
The cause for the user not being able to access the /etc/pki directory was due to them only having jailed ssh access. Once I granted full access, it all worked fine.
谢谢你的信息，雷米.
这篇关于对于非 root 用户在 CentOS 上的 SSL 连接 cURL 不起作用(错误 #77)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
