web-dev-qa-db-ja.com

非ルートユーザーのCentOS上のSSL接続でcURLが機能しない(エラー#77)

つい最近、私のWebサーバーのhttps://アドレスへのcurl要求に対するサーバーの動作が停止しました。少し掘り下げてみると、ウェブサーバーを実行しているユーザーに問題があるようです。

RootとしてサーバーにSSHで接続して呼び出した場合

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アカウント(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?)

問題に対する明確な答えを見つけることができませんでした。また、先週はうまく機能していましたが、ホスティング会社は「サポート対象外」であるため、支援を拒否しています。

http://curl.haxx.se/docs/sslcerts.html で言及が見つかりました

「libcurlがNSSサポート付きでビルドされた場合、OSディストリビューションに応じて、システム全体のCA証明書dbを使用するためにいくつかの追加手順が必要になる可能性があります。 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 

誰がこれが突然変わったのか、それともそれを修正する方が良いのかについていくつかの光を当てることができますか?

ありがとう

22
TobyG

問題は、スクリプトがcPanel "スクリプトにパイプされた電子メール"から実行されていたため、ユーザーとして実行されていたため、ユーザーの問題でしたが、Webサーバーにはまったく影響しなかったことが判明しました。

ユーザーが/ etc/pkiディレクトリにアクセスできない原因は、jailされたsshアクセスしか持っていないためです。フルアクセスを許可すると、すべて正常に機能しました。

情報をありがとう、レミ。

2
TobyG

無駄に同じエラーを検索したときに私が最近ここに到達した場合、CentOSで障害を引き起こすNSSの更新であることがわかります。 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- *が相互に必要であるためです。問題は、お互いのバージョンの互換性をチェックしておらず、場合によっては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

もちろん、最寄りのミラーからダウンロードして、正しいバージョン/ OSなどを確認する必要があります。基本的に、yumを修正するためにrpmからアップデートをダウンロードしてインストールします。 @grumpysysadminが指摘したように、コマンドを短くすることができます。 @cwgtexは、RPMコマンドを使用してアップグレードをインストールし、プロセスをより簡単にする必要があると考えています。

wordpressで問題を修正するには、httpサーバーを再起動する必要があります。

$ service httpd restart

もう一度試して、成功してください!

12
Will

CentOS7のError#77で同様の問題が発生しました。 ca-certificates RPMと共にインストールされるソフトリンク/ etc/pki/tls/certs/ca-bundle.crtがありませんでした。

「カール」はこのパスを開いて認証局を取得しようとしました。私が発見したのは:

strace curl https://example.com

そのリンクでオープンが失敗したことを明確に確認しました。

私の修正は:

yum reinstall ca-certificates

これですべてがセットアップされます。企業用または自己署名用のプライベートCAがある場合は、それらが再追加されるように/ etc/pki/ca-trust/source/anchorsにあることを確認してください。

3
DavidG

CA証明書バンドルに正しい権利が設定されていることを確認してください。通常、これは/ etc/ssl/certsディレクトリ内のCAファイル(たとえば/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='

ここも同じです。

2
Remi Gacogne

Ubuntuの場合:

Sudo apt-get install ca-certificates

Dockerfile内でROOTとして物事をカールしようとすると、この問題が発生します

1
WilderField

このエラーは、PKIディレクトリ内のSSLチェーン証明書ファイルが破損または欠落していることが原因です。次の手順に従って、ファイルがcaバンドルであることを確認する必要があります:コンソール/端末で:

mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates

このサイトを入力してください: https://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates 、ca-certificateを取得します。たとえば、 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 now、install yout rpm:

rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv

今、あなたのサービスを再起動します:私の例このコマンド:

Sudo service2 httpd restart

非常に素晴らしい見栄え

0

Httpsサーバーでcurlを実行しようとすると、同じ問題に直面していました。

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

キーストアパスを誤って設定すると、この問題が観察されました。キーストアパスを修正した後、機能しました。

0
rakeshz