Centos 7获得NSS错误的卷曲-12188
我试图发送一个GET请求到一个运行HTTPS的网站，但是总是得到curl: (35) Peer reports it experienced an internal error.，并且我只收到这个网站的错误。当我试图向Youtube、Google和其他HTTPS网站发送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上的卷曲是使用ECDHE-RSA256-GCM- that 384密码作为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但是，当我在well服务器上使用选定的密码运行curl时，出现了错误Unknown cipher in list，甚至我也使用了最新的curl版本并更新了我的well服务器。
[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有人能想办法解决这个问题吗？
回答 1
Stack Overflow用户
发布于 2020-03-21 01:04:10
首先:我使用了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一致，除非它在-4 --而不是卷曲7.68或OpenSSL 1.1.1d有nss。请检查您安装了什么yum，以及从什么回购(右栏)。
无论如何，我的curl/NSS 版本在该服务器上确实得到了相同的错误。用wireshark捕获和解码，它看起来像一个合理的TLS1.2 ClientHello。我的OpenSSL 1.0.2k (使用RH/CentOS添加的任何补丁) s_client都成功了(只要我指定了现在广泛需要但在1.0.2中不是默认的-servername )，在其他系统上为不同的1.0.2、1.1.0 (相同的服务器名)和1.1.1 (servername现在是默认的)构建的OpenSSL源代码也是如此。由于wget (可用于CentOS7)使用OpenSSL，wget继承了，并提供了与curl相同的功能。
经过一些实验(使用Java)，该服务器似乎在使用rfc5746扩展( NSS所做的)的另一个有效的TLS1.2 hello上失败，但如果使用SCSV ( OpenSSL做的)，则成功。这是相当糟糕的，因为rfc显然都需要服务器支持。但是，除非您对服务器上使用的软件或中间件的开发人员有一定的影响，否则您可能无法对此做任何事情，并且需要一个解决办法，例如wget。
看起来NSS一直在使用扩展而不是SCSV 自2013年以来。
更奇怪的是，Firefox使用NSS (虽然我找不到方法来判断哪个版本)，我现在的68 NSS发送了一个带有重新协商扩展的TLS1.3 ClientHello (而不是SCSV)并成功了。可能是服务器首先检查协议版本，然后以不同的方式处理rfc5746 (避免失败)，或者根本没有，因为TLS1.3禁止重新协商完全使rfc5746毫无意义。
https://stackoverflow.com/questions/60722492
复制相似问题
腾讯云开发者
