时间戳

首页 > 解决方案 > Centos 7 上的 CURL 出现 NSS 错误 -12188

curl - Centos 7 上的 CURL 出现 NSS 错误 -12188

问题描述

我试图向正在运行但总是收到GET的网站发送请求，并且我仅在该网站上收到此错误。当我尝试向 Youtube、Google 和其他 HTTPS 站点发送请求时，它们与我的 curl 配合得很好。这是我服务器上 curl 详细模式的信息。HTTPScurl: (35) Peer reports it experienced an internal error.GET

# curl -v https://***.vn > test.htm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   
  Trying 103.x.x.x:443...
* TCP_NODELAY set
* Connected to ***.vn (103.x.x.x) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: none
  CApath: none
* loaded libnssckbi.so
* NSS error -12188 (SSL_ERROR_INTERNAL_ERROR_ALERT)
* Peer reports it experienced an internal error.
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) Peer reports it experienced an internal error.

我已经更新了我的服务器yum update并将 curl 更新到最新版本，但仍然无法正常工作。之后，我尝试从我的 Macbook 发送请求，当阅读结果时，我知道我的 Mac 上的 curl 也使用 ECDHE-RSA-AES256-GCM-SHA384 密码作为 TSLv1.2。

Viets-MacBook-Pro:~ vietnguyen$ curl -v https://*****.vn > test.htm
* Rebuilt URL to: https://*****.vn/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 103.xx.xx.xx...
* TCP_NODELAY set
* Connected to *****.vn (103.xx.xx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [217 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3177 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: businessCategory=Private Organization; serialNumber=.....; CN=*****.vn
*  start date: Dec 11 06:22:40 2018 GMT
*  expire date: Dec 11 06:22:40 2020 GMT
*  subjectAltName: host "*****.vn" matched cert's "*****.vn"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Extended Validation CA - SHA256 - G3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: *****.vn
> User-Agent: curl/7.54.0
> Accept: */*
> 
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/10.0
< X-Powered-By: ASP.NET
< X-XSS-Protection: 1;mode=block
< Date: Thu, 20 Feb 2020 13:41:32 GMT
< Content-Length: 73711
< 
{ [7804 bytes data]
100 73711  100 73711    0     0  39172      0  0:00:01  0:00:01 --:--:-- 39166
* Connection #0 to host *****.vn left intact

但是当我在我的网络服务器上使用选定的密码运行 curl 时出现错误Unknown cipher in list，那么即使我使用最新的 curl 版本并更新我的网络服务器也是如此。

[root@localhost vietnguyen]# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 -v https://*****.vn > test.htm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 103.xx.xx.xx:443...
* TCP_NODELAY set
* Connected to *****.vn (103.xx.xx.xx) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Unknown cipher in list: ECDHE-RSA-AES256-GCM-SHA384
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (59) Unknown cipher in list: ECDHE-RSA-AES256-GCM-SHA384

我的卷曲版本

# curl -V
curl 7.68.0 (x86_64-redhat-linux-gnu) libcurl/7.68.0 NSS/3.44 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.9.0 nghttp2/1.31.1
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL UnixSockets

我也运行yum update nss nss-util nss-sysinit nss-tools到最新的 nss 版本仍然无法正常工作。

我的 openssl 版本

# openssl version
OpenSSL 1.1.1d  10 Sep 2019

谁能有任何想法来解决这个问题？

标签： curlopensslcentos7

解决方案

第一：我在 CentOS 7 上（更新后）

$ curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.44 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ yum list curl nss openssl 
[snip]
Installed Packages
curl.x86_64                       7.29.0-54.el7_7.2                    @updates
nss.x86_64                        3.44.0-7.el7_7                       @updates
openssl.x86_64                    1:1.0.2k-19.el7                      @anaconda
Available Packages
nss.i686                          3.44.0-7.el7_7                       updates
$ yum repolist
[snip]
repo id                             repo name                             status
base/7/x86_64                       CentOS-7 - Base                       10,097
extras/7/x86_64                     CentOS-7 - Extras                        335
updates/7/x86_64                    CentOS-7 - Updates                     1,774
repolist: 12,206

所有这些都与 rpmfind 一致，除了它的 nss 为 -4——不是 curl 7.68 或 OpenSSL 1.1.1d。请检查 yum 说您已安装什么，以及来自哪个 repo（右侧列）。

无论如何，我的 curl/NSS 版本在该服务器上确实出现了相同的错误。使用wireshark进行捕获和解码，看起来像是一个合理的TLS1.2 ClientHello。我的 OpenSSL 1.0.2k（带有 RH/CentOS 添加的任何补丁）s_client成功（只要我指定-servername现在广泛需要但在 1.0.2 中不是默认的），我在另一个系统上为各种 1.0 构建的 OpenSSL 源代码也是如此.2、1.1.0（相同的服务器名称）和 1.1.1（服务器名称现在是默认值）。由于 wget（可用于 CentOS7）使用 OpenSSL，因此wget 成功，并提供与 curl 基本相同的功能。

经过一些试验（使用 Java）后，该服务器似乎在使用 rfc5746 的扩展名（NSS 使用）的其他有效 TLS1.2 hello 上失败，但如果使用 SCSV（OpenSSL 使用）则成功。这是相当糟糕的，因为 rfc 显然需要服务器支持两者。但是，除非您对服务器上使用的软件或中间件的开发人员有一定的影响，否则您可能对此无能为力，需要使用 wget 等解决方法。

自 2013 年以来，NSS 似乎一直在使用扩展而不是 SCSV

更奇怪的是，Firefox 使用 NSS（虽然我找不到方法来判断哪个版本），而我当前的 68esr 发送一个带有重新协商扩展（不是 SCSV）的TLS1.3 ClientHello 并成功。可能是服务器首先检查协议版本，然后以不同的方式处理 rfc5746（避免失败）或根本不处理，因为 TLS1.3 完全禁止重新协商，使 rfc5746 没有实际意义。

推荐阅读