CouchDB无法通过SSL工作

lnlaulya  于 2022-12-09  发布在  CouchDB
关注(0)|答案(3)|浏览(203)

我运行的是CouchDB Docker container,V.2.1.1。此时除了SSL之外,其他一切都正常工作。我正在按照CouchDB文档中的SSL设置进行操作。容器具有OpenSSL 1.0.1t。
如文档中所示,我使用的是自签名证书。当我尝试连接到端口6984上的SSL页面时:
Chrome告诉我

"ERR_CONNECTION_CLOSED".

curl 给我

** curl -k https://localhost:6984**

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

在服务器日志中,我得到了很多这样的信息。

hello terminated with reason: no function clause matching ssl_cipher:hash_algorithm

搜索最后一个错误会发现Erlang版本有问题。但是,我相信CouchDB容器有一个已经修补过的版本。我确实尝试过升级:

apt-get install Erlang

这没有什么区别。搜索结果还指出OpenSSL的版本有问题。我从源代码升级到OpenSSL 1. 1. 1,重新创建了证书,但问题仍然存在。
按照要求,下面是几个命令的输出。

openssl s_client -连接本地主机:6984

CONNECTED(00000005)
140736008328136:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_lib.c:124:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

** curl --版本**

curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy

** curl -k -v https://localhost:6984**

* Rebuilt URL to: https://localhost:6984/
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 6984 (#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):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984
* stopped the pause stream!
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

curl -k --密码默认值https://localhost:6984

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

curl -k --密码ECDHE-RSA-AES 256-GCM-SHA 384 https://localhost:6984

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

下面三个命令的输出非常相似。我将只显示不同之处。但是,看起来所有这些命令现在都在进行握手。

$ openssl s_客户端-tls 1-连接本地主机:6984

CONNECTED(00000005)
SSL handshake has read 1762 bytes and written 400 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 18C5DF9DCA1B8AA0DBD33258BCD253053F8D1D91B524B0561A1C0FAB8CFB5146
    Master-Key: FD0C57E4E8FB992C0323D43930C104D82B69C4200F42E03EDB51E38A47448D62FDCB6E813583E2177A339B74B4D0CC4A
    Start Time: 1525593658
    Timeout   : 7200 (sec)

$路径/到/brew/版本/属于/openssl s_client -连接本地主机:6984

CONNECTED(00000003)
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
SSL handshake has read 1796 bytes and written 537 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-SHA256
    Session-ID: A19D67CBE634843181859DB2C3C4D1A3416C9F7DAA85CF470D412FE723AD49B4
    Master-Key: 61B711B9BEDB651868607527439D01B421780C7D584FCE68C4754A7A7F3563923409C03F4B68BB7914397B48A92FC756
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1525593604
    Timeout   : 300 (sec)

$路径/到/brew/版本/属于/openssl s_client -tls 1-连接本地主机:6984

SSL handshake has read 1762 bytes and written 397 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 6CC7FFE1C7CE258F105C7ADD5D8A9C0DFFB26A5A9555EB218EE48E519D361208
    Master-Key: 2D6DFAC01544F6FF5F4138D877A4105485D5A2F77B58B4796822625E2E602455C38E3EEB2CBACE07FA03D207B07C715E
    Start Time: 1525593717
    Timeout   : 7200 (sec)

$ curl -k --tlsv 1 https://localhost:6984

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

$ curl -k --tlsv1.0 https://localhost:6984

{"couchdb":"Welcome","version":"2.1.1","features":["scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

所以我猜LibreSSL的内置版本有问题?下一个问题是可以做些什么?

w51jfk4q

w51jfk4q1#

为了更深入地挖掘,您可以发布以下命令的输出吗?

$ openssl s_client -connect localhost:6984

$ curl --version

$ curl -k -v https://localhost:6984

$ curl -k --ciphers DEFAULT https://localhost:6984

$ curl -k --ciphers ECDHE-RSA-AES256-GCM-SHA384 https://localhost:6984

顺便说一下,我注意到您的curl使用的是LibreSSL而不是OpenSSL,如您收到的错误消息所示:
(35)LibreSSLSSL连接:SSL_ERROR_SYSCALL正在连接到本地主机:6984
当您尝试openssl:

$ openssl s_client -connect localhost:6984

您收到此错误:
已连接(0000005)140736008328136:错误:140790 E5:SSL例程:SSL23_WRITE:SSL握手失败:/构建根目录/库/缓存/com.apple.xbs/源代码/libressl/libressl-22.50.2/libressl/ssl/s23_lib.c:124:
请报告此命令的输出:

$ openssl s_client -tls1 -connect localhost:6984

此外,也可以推断出问题的原因是您的macOS默认版本的LibreSSL/OpenSSL。要修复此问题,请尝试安装brew版本的OpenSSL,然后再次运行此命令,并报告输出:

$ path/to/brew/version/of/openssl s_client -connect localhost:6984

也请张贴的输出这太:

$ path/to/brew/version/of/openssl s_client -tls1 -connect localhost:6984

根据您报告的输出,请尝试以下命令,看看它是否有效:

$ curl -k --tlsv1 https://localhost:6984
5f0d552i

5f0d552i2#

如果SSL证书是自签名证书:
您没有显示curl命令,但我猜您没有使用-k选项,但您应该:

-k, --insecure
              (TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even  for
              server connections otherwise considered insecure.
kognpnkq

kognpnkq3#

我不能肯定地说,这是实际的答案,以特定的问题,操作程序有大约三年前和计数,但这里有一个答案-至少我的问题是什么时,调试相同的错误。
在我的例子中,我从macOS转向了Linux Mint,并从MacPorts和Homebrew转向了更适合和更少以用户为中心的软件处理方式。
我之所以说不那么以用户为中心,是因为问题的根源就在这里。特别是,我已经将我所有的开发和配置文件从macOS系统同步到了这个新的Mint系统上,而且在我的Mac上,我的方法是以我的身份运行nginx,php-fpm,couchdb等--也就是说,以daniel:staff的身份,那么我在~/Projects/SSL中找到的SSL证书也归我所有。
而且,因为最佳实践是用0600 umask锁定证书,并且一些应用程序拒绝运行,所以除了我之外,任何人都无法读取我的证书,包括couchdb用户,在“正确配置”的系统(如Linux)上,couchdb默认以couchdb用户身份运行。
SSL_ERROR_SYSCALL确实提示了这一点-至少,它提示了与系统调用相关的错误,而不是证书结构本身的错误。
此外,我们还看到No client certificate CA names sentread 0 bytesNew, (NONE), Cipher is (NONE)和其他几个NONE,所有这些都暗示实际上没有读取任何内容。
同样,OP的问题可能是不同的,但在我的情况下,SSL文件上的一个简单的chmod允许couchdb实际读取它们,而不是在这里呕吐。
我将继续生成一个新的自签名证书,并将其显式地提供给couchdb,但无论如何,这就是我的特定机器上这些错误背后的问题。

相关问题