对于非root用户,cURL在CentOS上的SSL连接不起作用(错误#77)

Tob*_*byG 23 ssl curl centos nss

就在最近,我的服务器已经停止了对我的Web服务器的https://地址的curl请求.稍微挖了一下,看起来这是网络服务器运行的用户的问题.

如果我以root用户身份SSH到服务器上并打电话

curl -I -v https://google.com
Run Code Online (Sandbox Code Playgroud)

...我收到以下回复......

* 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: */*
Run Code Online (Sandbox Code Playgroud)

但是,如果我以任何cPanel帐户登录(也通过Web服务器运行时使用),我会得到以下内容......

* 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?)
Run Code Online (Sandbox Code Playgroud)

我无法找到问题的确切答案,我的托管公司拒绝提供帮助,因为它"没有支持",即使它上周工作正常!

我确实在http://curl.haxx.se/docs/sslcerts.html上找到了提及

"如果libcurl是使用NSS支持构建的,那么根据操作系统分布,可能需要采取一些额外的步骤来使用系统范围的CA证书数据库.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 
Run Code Online (Sandbox Code Playgroud)

任何人都可以解释为什么这可能会突然改变,或者更好的仍然是如何解决它?

谢谢

小智 14

如果你最近到达这里,就像我在搜索相同的错误时所做的那样,你可能会发现它是对NSS的更新导致CentOS失败.通过运行yum update进行测试并查看是否出现错误,curl也会创建此错误.解决方案很简单,只需手动安装NSS即可.

继续阅读......

如果你像我一样,它会抛出类似这样的错误:

curl: (77) Problem with the SSL CA cert (path? access rights?)
Run Code Online (Sandbox Code Playgroud)

这需要一些时间来解决,但发现它不是CA证书,因为通过重新创建它们并检查我已经排除它的所有配置.它可能是libcurl所以我去寻找更新.

如上所述,我重新创建了CA证书.你也可以这样做,但这可能是浪费时间.http://wiki.centos.org/HowTos/Https

下一步(可能应该是我的第一步)是通过简单地运行yum来检查一切是否是最新的.

$ yum update
$ yum upgrade
Run Code Online (Sandbox Code Playgroud)

这给了我一个肯定的答案,即在游戏中存在更大的问题: 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-*需要彼此起作用.问题是他们没有检查彼此版本的兼容性,在某些情况下它最终打破了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
Run Code Online (Sandbox Code Playgroud)

您当然应该从最近的镜像下载并检查正确的版本/操作系统等.我们基本上从rpm下载并安装更新以修复yum.正如@grumpysysadmin所指出的,你可以缩短命令.@cwgtex认为您应该使用RPM命令安装升级,这使得该过程更加简单.

要使用wordpress修复问题,您需要重新启动http服务器.

$ service httpd restart
Run Code Online (Sandbox Code Playgroud)

再试一遍,成功!


Wil*_*eld 6

对于 Ubuntu:

sudo apt-get install ca-certificates
Run Code Online (Sandbox Code Playgroud)

尝试在 Dockerfile 中将内容卷曲为 ROOT 时遇到此问题


Dav*_*idG 5

我在CentOS7上的Error#77遇到了类似的问题。我缺少随ca-certificates RPM安装的软链接/etc/pki/tls/certs/ca-bundle.crt

“ curl”正试图打开此路径以获取证书颁发机构。我发现:

strace curl https://example.com
Run Code Online (Sandbox Code Playgroud)

并清楚地看到在该​​链接上打开失败。

我的解决方法是:

yum reinstall ca-certificates
Run Code Online (Sandbox Code Playgroud)

那应该重新设置一切。如果您具有供公司或自签名使用的专用CA,请确保它们位于/ etc / pki / ca-trust / source / anchors中,以便重新添加它们。

  • 甜的!重新安装也解决了我的问题。 (3认同)

Tob*_*byG 3

事实证明,问题在于脚本是从 cPanel“通过电子邮件传送到脚本”运行的,因此是以用户身份运行的,因此这是一个用户问题,但根本不影响 Web 服务器。

用户无法访问 /etc/pki 目录的原因是他们只有被监禁的 ssh 访问权限。一旦我授予完全访问权限,一切就正常了。

不过,谢谢你的信息,雷米。