cURL对于非root用户的CentOS上的SSL连接不工作（错误＃77） [英] cURL not working (Error #77) for SSL connections on CentOS for non-root users

问题描述

刚刚我的服务器已停止为我的Web服务器的https：//地址的curl请求工作。有一个挖了一下它似乎是一个问题与用户web服务器正在运行。

如果我SSH到服务器作为root&

  curl -I -v https://google.com 
  pre> 
 
 
 ...我得到以下响应... 
  *关于连接（）到google.com端口443（＃0）
 *尝试173.194.67.113 ...连接
 *连接到google.com（173.194.67.113）端口443 ）
 *使用certpath：sql初始化NSS：/ etc / pki / nssdb 
 * CAfile：/etc/pki/tls/certs/ca-bundle.crt 
 CApath：none 
 * SSL连接使用SSL_RSA_WITH_RC4_128_SHA 
 *服务器证书：
 *主题：CN = *。google.com，O = Google Inc，L = Mountain View，ST = California，C = US 
 *开始日期：5月22日15:50:20 2013 GMT 
 *到期日：10月31日23:59:59 2013 GMT 
 *通用名称：* .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 
>主机：google.com 
>接受：* / * 
  
但是，如果我以任何cPanel帐户通过web服务器运行）我得到以下... 
  *关于连接（）到google.com端口443 ＃0）
 *尝试173.194.67.101 ...连接
 *连接到google.com（173.194.67.101）端口443（＃0）
 *使用certpath初始化NSS：none 
 * NSS错误-5978 
 *关闭连接＃0 
 * SSL CA证书问题（路径？访问权限？）
 curl：（77）SSL CA证书路径？访问权限？）
  
我无法找到问题的确定答案， &我的托管公司拒绝帮助，因为它是不支持，即使它在上周工作很好！
 
 
 
我在http://curl.haxx.se/docs/sslcerts.html  
 
 
如果libcurl是使用NSS支持构建的，那么根据操作系统分发，
，可能需要采取一些额外的步骤来使用系统范围的CA 
 cert db。 RedHat附带一个额外的模块libnsspem.so，它允许
 NSS读取OpenSSL PEM CA bundle。这个库在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 
协议：tftp ftp telnet dict ldap ldaps http文件https ftps scp sftp 
特性：GSS协商IDN IPv6大文件NTLM SSL libz 
  
任何人都可以了解为什么这可能突然改变， 
 
 
 
感谢
解决方案
面对的是脚本从cPanel电子邮件管道到脚本运行，所以作为用户运行，所以是一个用户问题，但不影响Web服务器。
 
 
 
用户无法访问/ etc / pki目录的原因是由于他们只有ssh访问ssh。一旦我授予完全访问权限，就一切正常。
 
 
 
感谢您的信息，Remi。
 
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.

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: */*
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!

I did find mention on http://curl.haxx.se/docs/sslcerts.html that

  
"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"
... but I can find no information on how I get this working system-wide on my CentOS server.

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 
Can anyone shed some light on why this might have suddenly changed, or better still how to fix it?

Thanks
解决方案
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.

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.

Thanks for the info though, Remi.

                        
这篇关于cURL对于非root用户的CentOS上的SSL连接不工作（错误＃77）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！