CouchDB 无法通过 SSL 工作答案

【问题标题】：CouchDB won't work over SSLCouchDB 无法通过 SSL 工作
【发布时间】：2018-10-10 18:16:50
【问题描述】：

我正在运行CouchDB Docker container，V.2.1.1。除 SSL 外，此时一切正常。我正在关注CouchDB documentation on SSL setup。该容器具有 OpenSSL 1.0.1t。

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

Chrome 告诉我

"ERR_CONNECTION_CLOSED".

卷曲给我

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 -connect localhost: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 --version

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 DEFAULT 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 的内置版本有问题？下一个问题是可以做些什么呢？

【问题讨论】：

标签： ssl openssl couchdb

【解决方案1】：

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

$ 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) LibreSSL SSL_connect: SSL_ERROR_SYSCALL 连接到本地主机：6984

当你尝试 openssl 时：

$ openssl s_client -connect localhost:6984

您收到此错误：

已连接（00000005）140736008328136：错误：140790E5：SSL 例程：SSL23_WRITE:ssl 握手失败：/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

【讨论】：

我在我的 Mac 上使用 curl。我在 docker 容器中使用 OpenSSL 来创建证书。 Docker 容器在同一台机器上运行，我已经打开了容器上的端口。因此，当我调用 curl localhost 时，这是在我的 Mac OS 上，但它应该被转发到 docker 容器，对吗？当我在没有 SSL 的情况下执行相同操作时，它可以工作。
我已经发布了您要求的输出。似乎 LibreSSL 的安装可能是问题所在。我不确定如何解决这个问题，因为它是由 Apple 提供的，而且似乎没有办法替换它。
@user1757006 请查看我的更新答案并报告输出。
你是怎么解决这个@user1757006的？

【解决方案2】：

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

【讨论】：

我使用的是自签名证书。使用 -k 选项会产生同样的错误。
我没有在我的 Mac 上解决这个问题，但我只是在我的笔记本电脑上测试，所以我不在乎。当我转向生产时，我当然不会使用自签名证书。

【解决方案3】：

我不能肯定这是对 OP 大约三年前遇到的特定问题的实际答案，而且还在不断增加，但这是一个答案——至少是我在调试相同错误时遇到的问题。

就我而言，我正在从 macOS 迁移到 Linux Mint，进而从 MacPorts 和 Homebrew 迁移到 apt 且不以用户为中心的软件处理方式。

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

而且，由于最佳做法是使用 0600 umask 锁定您的证书，如果不是，某些应用程序会拒绝运行，因此除了我之外的任何人都无法读取我的证书，包括 couchdb 用户couchdb 默认在 Linux 等“正确配置”的系统上运行。

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

此外，我们看到No client certificate CA names sent、read 0 bytes、New, (NONE), Cipher is (NONE) 和更多NONEs，都暗示实际上没有被阅读。

同样，可能是 OP 的问题不同，但在我的情况下，SSL 文件上的一个简单的chmod 允许 couchdb 实际读取它们而不是在这里抛出。

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

【讨论】：