【问题标题】:cURL SSL connect error 35 with NSS error -5961cURL SSL 连接错误 35 和 NSS 错误 -5961
【发布时间】:2014-03-20 04:28:34
【问题描述】:

我有一个远程 Windows 7 服务器,只能通过端口 768 上的 HTTPS 访问。该服务器正在使用来自本地 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 XP 而不是 Windows 7 的远程服务器。

我尝试强制 cURL 使用 SSLv3(使用 -3 标志和 -SSLv3 标志)但没有成功。


我刚刚在运行 Raspbian 的 Raspberry Pi 上测试了相同的 CURL 命令,并且能够成功连接。因此,我认为这可能是 CentOS 服务器上使用的 cURL 版本的问题。树莓派正在运行以下版本:

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

【问题讨论】:

  • 我遇到了同样的问题。我更新了 openssl、curl、lib-curl 和其他东西。无法解决。最后,我认为需要为目标服务器上的此端口制定防火墙策略。在源服务器和目标服务器之间打开端口后问题解决。

标签: curl ssl windows-7 centos


【解决方案1】:

我最近在 CentOS 6 机器上遇到了同样的问题。原来是服务器很久没更新了,NSS版本太旧了。通过更新 curl 和 NSS 修复:

yum update -y nss curl libcurl

【讨论】:

  • 我更新了 curl libcurl 和 ca-certificates,但忘记了 nss。那是给我的票,谢谢!
  • 是的。那为我修好了。谢谢。
  • 2.6.32-573.12.1.el6.centos.plus.x86_64,已解决问题。
  • 对我来说它不起作用,因为我有一个需要 TLS 1.2 的第三方存储库。在那种情况下,我不得不使用 yum 选项 --disablerepo 暂时排除该 repo。例如:yum --disablerepo=<some-repo-id> update -y nss curl libcurl
【解决方案2】:

当客户端和服务器之间的密码不重叠时也会发生这种情况。

例如服务器只接受 ECHDE 密码,但客户端(一些用 nss 构建的旧版本 curl)没有这个密码。

在这种情况下,当服务器发现没有密码重叠时,服务器将向客户端发送 TCP RST 以终止 SSL 连接尝试(客户端将在 'client hello' 中包含支持的密码)。

【讨论】:

    【解决方案3】:

    当服务器不支持 ssl 协议时也会出现此错误,请尝试在 server.xml 文件中指定所有变体/协议。

    【讨论】:

      【解决方案4】:

      curl 使用 NSS 默认从 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
      

      您可以通过 curl 的选项 --cacert 使用包含 CA 证书的 PEM 文件指定另一个(您的)CA 证书(或捆绑在 NSS Shared DB 上)。

      如果您不使用 --cacert 选项手动指定证书,NSS 会尝试自动从 NSS 数据库(位于 /etc/pki/nssdb)中选择正确的证书。您可以通过 curl 的选项 --cert 指定它的昵称,如果密钥嵌入在证书中,这应该足够了,如果没有,您可以使用 --key 指定带有证书密钥的 PEM 文件。如果密钥受密码保护,您可以通过 curl 的选项--pass 提供它,这样您就可以使用nss-tools (yum install nss-tools) 将您的证书导入到 NSS 共享数据库中

      添加证书(常用命令行)

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

      关于 TRUSTARGS

      指定要在现有证书中修改或在创建证书或将其添加到数据库时应用到证书的信任属性。

      每个证书都有三个可用的信任类别, 按此顺序表示:“ SSL 、电子邮件 、对象签名”。每个 类别位置使用以下属性代码中的零个或多个:

      • p 禁止(明确不信任)
      • P 可信对等体
      • c 有效的 CA
      • T 受信任的 CA 颁发客户端证书(隐含 c)
      • C 受信任的 CA 颁发服务器证书(仅限 SSL)(隐含 c)
      • u 证书可用于身份验证或签名
      • w 发送警告(与其他属性一起使用以在该上下文中使用证书时包含警告)

      类别的属性代码用逗号分隔,并且 用引号括起来的整个属性集。例如:

      -t "TCu,Cu,Tuw"

      信任根 CA 证书来颁发 SSL 服务器证书

      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>
      

      希望这会有所帮助。

      【讨论】:

        【解决方案5】:

        发生了什么

        听起来您在连接到 Windows 7 服务器时遇到了超时问题。

        可能的解决方案

        一个可能的answer 表示错误5961 的根本原因原来是网络MTU 设置问题。目前尚不清楚您是否有权访问 Windows 7 服务器或环境的完整组件,以确定导致连接失败的超时的确切原因。我会检查 Windows 7 服务器的 MTU 并将 MTU 设置与其他服务器的设置进行比较。如果您发现需要修改设置,可以关注此procedure

        【讨论】:

        • 您好 Tommie C。我对 Windows 7 服务器的访问权限有限。我用运行 OpenSuse 而不是 CentOS 的主机启动了一个不同的虚拟机(OpenSuse 似乎带有用 OpenSSL 而不是 NSS 编译的 cURL)。这个新的虚拟机连接到 Windows XP 或 Windows 7 服务器都没有问题。因此,我相信 NSS 可能在某种程度上是罪魁祸首(或者至少是与 CentOS 6.5 一起分发的版本)。
        猜你喜欢
        • 2018-06-16
        • 2019-02-13
        • 2016-08-15
        • 1970-01-01
        • 2016-09-16
        • 2016-05-07
        • 2011-03-15
        • 2016-04-28
        • 2021-10-24
        相关资源
        最近更新 更多