openCouchDB 无法通过 SSL 工作



我正在运行CouchDB Docker容器V.2.1.1。此时一切正常,除了SSL。我正在遵循有关SSL设置的CouchDB文档。容器具有OpenSSL 1.0.1t。

如文档所示,我使用的是自签名证书。当我尝试连接到端口 6984 上的 SSL 页面时:

铬告诉我

"ERR_CONNECTION_CLOSED".

卷曲给我

卷曲 -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 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 --ciphers 默认 https://localhost:6984

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

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

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

以下三个命令的输出非常相似。我只会展示差异。但是,似乎现在正在与所有这些命令握手。

$ openssl s_client -tls1 -connect localhost: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)

$ path/to/brew/version/of/openssl s_client -connect localhost: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)

$ path/to/brew/version/of/openssl s_client -tls1 -connect localhost: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 --tlsv1 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 的内置版本有问题?下一个问题是可以做些什么?

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

$ 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,如您收到的错误消息所示:

curl: (35)LibreSSLSSL_connect: SSL_ERROR_SYSCALL 本地主机:6984


当您尝试打开时:

$ openssl s_client -connect localhost:6984

您收到此错误:

已连接(00000005) 140736008328136:错误:140790E5:SSL 例程:SSL23_WRITE:SSL 握手 failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/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

如果您的 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.

我不能确定这是 OP 大约三年前遇到的特定问题的实际答案,并且还在不断增加,但这里有一个答案——至少在调试相同的错误时我的问题是什么。

就我而言,我正在从macOS转向Linux Mint,并扩展为从MacPorts和Homebrew转向适当且不那么以用户为中心的软件处理方式。

我说不那么以用户为中心,因为问题的根源源于这里。特别是,我已经将所有开发和配置文件从我的macOS系统同步到这个新的Mint系统,并且由于我的Mac上的方法是以我的身份运行nginx,php-fpm,couchdb等 - 也就是说,作为daniel:staff,那么我在~/Projects/SSL中找到的SSL证书也归我所有。

而且,由于最佳实践是使用0600umask 锁定您的证书,并且某些应用程序拒绝运行,如果它们不是,那么除了我之外,任何人都无法读取我的证书,包括 couchdb 默认在"正确配置"的系统(如 Linux)上运行的couchdb用户。

SSL_ERROR_SYSCALL确实暗示了这一点——至少,它暗示了与系统调用相关的错误,而不是证书结构本身的错误。

此外,我们看到No client certificate CA names sentread 0 bytesNew, (NONE), Cipher is (NONE)和另外几个NONE,所有这些都暗示没有实际被读取。

同样,可能是OP的问题不同,但就我而言,SSL文件上的简单chmod允许couchdb实际读取它们而不是在这里抛出。

我继续生成一个新的自签名证书并将其显式提供给 couchdb,但无论如何,这是我特定盒子上这些错误背后的问题。

最新更新