web-dev-qa-db-ja.com

NSSエラー-5961を含むcURL SSL接続エラー35

ポート768のHTTPS経由でのみアクセス可能なリモートWindows 7サーバーがあります。サーバーは、ローカルCentOSサーバーにリストされているCAからの署名付き証明書を使用しています。

次のコマンドを使用してcURL経由でリモートサーバーにアクセスしようとすると、次のようにエラーが発生します。

[usr@serv certs]# curl -3 -v https://1.1.1.1:768/user/login
* About to connect() to 1.1.1.1 port 768 (#0)
*   Trying 1.1.1.1... connected
* Connected to 1.1.1.1 (1.1.1.1) port 768 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

(IPアドレスはセキュリティ上の理由で隠されていることに注意してください)。

次のバージョンのcURLを実行しています。

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

これは、Windows 7ではなくWindows XPを実行している他の2つのリモートサーバーで動作していることに注意してください。

CURLにSSLv3を強制的に使用しようとしましたが(-3フラグと-SSLv3フラグを使用)、成功しませんでした。


Raspbianを実行しているRaspberry Piで同じCURLコマンドをテストしたところ、正常に接続できました。したがって、CentOSサーバーで使用されているcURLのバージョンに問題がある可能性があります。 Raspberry Piは次のバージョンを実行しています。

curl 7.26.0 (arm-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps Gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
18
euantorano

NSSを使用するcurlは、デフォルトでPEM形式の"/etc/pki/tls/certs/ca-bundle.crt"からルートCA証明書を読み取ります。

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt

CA証明書を含むPEMファイルでcurlのオプション--cacertを使用して、別の(自分の)CA証明書(または NSS共有DB のバンドル)を指定できます。

--cacertオプションを使用して証明書を手動で指定しない場合、NSSは(/etc/pki/nssdbにある)NSSデータベースから適切な証明書を自動的に選択しようとします。 curlのオプション--certでニックネームを指定できます。キーが証明書に埋め込まれている場合はこれで十分です。そうでない場合は、--keyを使用して証明書キーでPEMファイルを指定できます。キーがパスフレーズで保護されている場合、curlのオプション--passで指定できるため、 nss-toolsyum install nss-tools

証明書の追加(共通コマンドライン)

certutil -d sql:/etc/pki/nssdb -A -t <TRUSTARGS> -n <certificate nickname> -i <certificate filename>

TRUSTARGSについて

信頼属性を指定して、既存の証明書を変更するか、証明書を作成またはデータベースに追加するときに証明書に適用します。

各証明書には、「SSL、電子メール、オブジェクト署名」の順序で表された3つの利用可能な信頼カテゴリがあります。各カテゴリの位置では、次の属性コードを0個以上使用します。

  • pは禁止(明示的に不信)
  • P信頼できるピア
  • c有効なCA
  • T信頼されたCAがクライアント証明書を発行する(cを含む)
  • Cサーバー証明書を発行するための信頼できるCA(SSLのみ)(cを含む)
  • u証明書は認証または署名に使用できます
  • w警告を送信します(証明書がそのコンテキストで使用されたときに警告を含めるために他の属性とともに使用します)

カテゴリの属性コードはコンマで区切られ、属性のセット全体が引用符で囲まれています。例えば:

-t "TCu、Cu、Tuw"

SSLサーバー証明書を発行するためのルートCA証明書の信頼

certutil -d sql:/etc/pki/nssdb -A -t "C,," -n <certificate nickname> -i <certificate filename> 

中間CA証明書のインポート

certutil -d sql:/etc/pki/nssdb -A -t ",," -n <certificate nickname> -i <certificate filename>

自己署名サーバー証明書の信頼

certutil -d sql:/etc/pki/nssdb -A -t "P,," -n <certificate nickname> -i <certificate filename> 

SSLクライアント認証用の個人証明書と秘密鍵の追加

pk12util -d sql:/etc/pki/nssdb -i PKCS12_file_with_your_cert.p12

NSS DBに保存されているすべての証明書の一覧表示

certutil -d sql:/etc/pki/nssdb -L

証明書の詳細の一覧表示

certutil -d sql:/etc/pki/nssdb -L -n <certificate nickname>

証明書の削除

certutil -d sql:/etc/pki/nssdb -D -n <certificate nickname>

お役に立てれば。

18
vzamanillo

最近、CentOS 6ボックスで同じ問題に遭遇しました。サーバーがかなり長い間更新されておらず、NSSバージョンが古すぎることが判明しました。 curlとNSSの両方を更新することで修正されました。

yum update -y nss curl libcurl
9
qingbo

このエラーは、sslプロトコルがサーバーでサポートされていない場合にも発行されます。server.xmlファイルですべてのバリアント/プロトコルを指定してください。

1
user4737628

何が起こっているのか

Windows 7サーバーへの接続時にタイムアウトの問題が発生しているように聞こえます。

可能な解決策

考えられる1つの answer は、エラー5961の根本原因がネットワークMTU設定の問題であることが判明したことを示しています。接続が失敗する原因となっているタイムアウトの正確な原因を特定するために、Windows 7サーバーまたは環境の完全なコンポーネントにアクセスできるかどうかは明確ではありません。 Windows 7サーバーのMTUを確認し、MTU設定を他のサーバーのMTU設定と比較します。設定を変更する必要がある場合は、この 手順 に従うことができます。

1
Tommie C.

これは、クライアントとサーバー間の暗号が重複していない場合にも発生します。

たとえば、サーバーはECHDE暗号のみを受け入れますが、クライアント(nssで構築された古いバージョンのcurl)にはこの暗号がありませんでした。

この場合、サーバーはTCP RSTをクライアントに送信して、暗号の重複がないことを検出するとSSL接続の試行を終了します(クライアントは 'client hello'でサポートされる暗号を含みます)。

0
hgfeaon