ポート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
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-tools (yum 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>
お役に立てれば。
最近、CentOS 6ボックスで同じ問題に遭遇しました。サーバーがかなり長い間更新されておらず、NSSバージョンが古すぎることが判明しました。 curlとNSSの両方を更新することで修正されました。
yum update -y nss curl libcurl
このエラーは、sslプロトコルがサーバーでサポートされていない場合にも発行されます。server.xmlファイルですべてのバリアント/プロトコルを指定してください。
これは、クライアントとサーバー間の暗号が重複していない場合にも発生します。
たとえば、サーバーはECHDE暗号のみを受け入れますが、クライアント(nssで構築された古いバージョンのcurl)にはこの暗号がありませんでした。
この場合、サーバーはTCP RSTをクライアントに送信して、暗号の重複がないことを検出するとSSL接続の試行を終了します(クライアントは 'client hello'でサポートされる暗号を含みます)。