5

我在云 (AWS) 中的 Ubuntu 12.10 服务器上运行 Apache CouchDB 实例（版本 1.3.0）。我正在尝试让 SSL 在我的 couchDB 实例上工作。

基本的 SSL 设置非常简单。我已将证书和密钥放在一个目录中，并在我的 local.ini 文件中取消注释以下行

httpsd = {couch_httpd, start_link, [https]}
cert_file = /usr/local/etc/couchdb/certs/mycouchdbserver_cert.pem
key_file = /usr/local/etc/couchdb/certs/mycouchdbserver_key.pem

我还确保这些文件的所有权是正确的。

这工作正常，couchDB 服务器启动，您可以毫无问题地导航到https://mycouchdbserver.com/_utils/。

使用 openssl 进行测试

openssl s_client -showcerts -connect mycouchdbserver.com:443

给出标准 SSL 配置的正确结果

在 DigiCert 网站上测试设置时（购买 SSL 证书的公司 - 测试链接：http ://www.digicert.com/help/ ）我收到以下错误：

服务器未发送所需的中间证书。

购买 SSL 证书时，我从 DigiCert 获得了中间证书，并且还下载了 DigiCert 的根证书。

在 couchDB 的 local.ini 配置文件中，您可以将它们与以下配置字段一起使用：

verify_ssl_certificates = true
cacert_file = xxxx

我的问题是我无法让它工作，并尝试了所有可能的组合来让它工作。这是我尝试过的：

  1. 尝试将 cacert_file 设置为来自 DigiCert 的中间证书
  2. 尝试将 cacert_file 设置为 /etc/ssl/certs 中的根证书
  3. 尝试将 DigiCert 网站的根证书添加到 /usr/shared/ca-certs/ 然后运行 ​​dpkg-reconfigure ca-certificates 以安装新的根证书并将 cacert_file 设置为 /etc/ssl/certs 中的新 pem 编码证书
  4. 尝试将证书和中间证书组合在一个用于 cert_file 的文件中
  5. 尝试将证书、中间证书和根证书组合到 1 个用于 cert_file 的 pem 文件中

以上所有内容都会在 couchDB 日志中引发错误。有些人在错误日志中提供大量输出，但使用数字 3，我得到

=ERROR REPORT==== 11-Jun-2013::11:35:30 ===
SSL: hello: ssl_handshake.erl:252:Fatal error: internal error

并用 openssl 测试我得到

CONNECTED(00000003)
16871:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal    error:s3_pkt.c:1099:SSL alert number 80
16871:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

有没有人知道如何正确使用 verify_ssl_certificates、根证书和中间证书与 couchDB

我已在线阅读所有文档，但没有任何帮助

在此先感谢安德鲁

4

3 回答 3

4

对于任何感兴趣的人，这就是我们最终解决问题的方式：

似乎我们无法让 couchDB 与我们的中间证书一起正常工作。

由于我们在 AWS EC2 实例上运行我们的 couchDB 服务器，我刚刚创建了一个 ELB（弹性负载均衡器）实例并将我的证书上传到 ELB，然后在我的负载均衡器下添加了 EC2 实例并将我的 DNS 重新路由到负载均衡器（在这里也使用 Route53）。

然后我在 couchDB 上完全关闭 SSL，并将 SSL 握手交给支持使用中间证书的负载均衡器。

这确实意味着 ELB 和 couchDB 之间的通信是不安全的，但对我们来说这很好。

这也意味着我们现在可以在 ELB 下添加更多的 couchDB 服务器以实现可扩展性，从而实现 2 鸟 1 石解决方案。

您也可以使用 Nginx 执行相同的解决方案，但是添加和管理 ELB 既简单又稳定，因此我们选择了 ELB 解决方案。

于 2013-06-14T07:33:19.783 回答
4

CouchDB 对一些事情很敏感。一个问题是 namecheap 的重新发行表格。如果你使用 namecheap 来处理你的 CSR，你会遇到问题。例如，我通过 Namecheap 购买了 RapidSSL 证书，为了正确重新颁发它，我必须直接前往 GeoTrust 以获得有效的证书：https ://products.geotrust.com/orders/orderinformation/authentication.do

要创建 SSL 证书，我执行了以下操作：

$ openssl genrsa -des3 -out server.pem 2048

使用了密码。它必须用于其他命令不要忘记它。

创建证书请求：

$ openssl req -new -key server.pem -out server.csr

只回答以下问题：

  • 国家
  • 状态
  • 地方性
  • 组织
  • 通用名称

所有其他问题都留空。

此命令创建 CouchDB 将使用的未加密私钥：

$ openssl rsa -in server.pem -out server.key

当要求提供 csr 时，将 server.csr 文件的内容粘贴到文本框中。

经过一堆电子邮件，您最终将获得证书。另一个问题是 CouchDB 如何处理链式证书。不用担心创建链式证书；忽略中间 crt，您只需要域的特定证书即可使 couchdb 正常工作。

修改 CouchDB local.ini 文件中的以下行：

[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
httpsd = {couch_httpd, start_link, [https]}

[ssl]
cert_file = /path/to/ssl/cert/server.crt
key_file = /path/to/ssl/cert/server.key

我不确定这是否会有所作为，但请确保 SSL 证书的权限设置为 600。还要确保 CouchDB 进程用户对证书进行 chown：

# in the ssl cert directory
sudo chmod 600 ./*
sudo chown couchdb:couchdb ./*

并重新启动您的服务器：

sudo /etc/init.d/couchdb restart
于 2013-07-21T19:00:00.770 回答
1

摘要：您需要 CouchDB 1.6.0 或更高版本才能工作（或修补您的当前版本）。

我在运行 CouchDB 1.4.0 或 Raspberry Pi (raspbian jessie) 时遇到了同样的问题。

我使用以下命令确认 CouchDB 服务器仅发送自己的证书，而不是 TLS 规范所要求的整个证书链：

openssl s_client -connect myhostname:6984 -showcerts

这仅显示一个证书。此外，它还报告了验证失败。我的证书来自 Namecheap。虽然我在客户端计算机上安装了颁发者的根证书 (COMODO RSA)，但至少需要一个中间证书才能完成该链。

请注意，某些浏览器能够自动获取中间证书并且一切看起来都很好。但是，大多数命令行工具（curl、perl、python、openssl）都失败了。同样有趣的是，在 Android 的 Chrome 浏览器上，它偶尔会显示绿色锁（一切正常），并且有时会报告该站点无法验证。我怀疑它正在使用本地证书缓存。如果我碰巧浏览了一个提供相同中间证书的站点，那么我的 CouchDB 服务器的验证随后会成功，直到缓存被清除。

在深入研究 CouchDB 和 Erlang 源代码后，我发现以下内容： Erlang 可以将 PEM 文件作为“cacertfile”传递。这既用于验证客户端证书（如果启用），也用于组成要在 TLS 证书消息中发送给客户端的完整证书链。但是，我的 CouchDB 版本没有传递cacertfile参数，除非指定cacert_file AND verify_ssl_certificates = true。但是，如果满足这些条件，它将省略服务器密钥和证书！

我发现这已经被归档为 bug COUCHDB-2028。请注意，该错误表示这已在版本 1.7.0 中得到解决，我认为该版本不存在。

我发现该修复程序已于 2014 年 1 月 30 日应用于官方 CouchDB 存储库。不幸的是，官方的修订历史并没有显示修复，但是通过 git repo 挖掘发现该修复首先在 CouchDB 1.6.0 中正式发布。

就我而言，我能够从源代码下载、编译和安装 CouchDB 1.6.1。现在，上面的openssl命令显示了由 CouchDB 服务器发送的 4 个证书链。我提供服务器密钥和证书，以及cacert_file从 Namecheap 下载的 CA 包。verify_ssl_certificates是假的。我测试过的所有浏览器都信任该站点，而且我的命令行工具可以在没有黑客攻击的情况下运行以禁用验证。

于 2016-09-17T20:20:17.490 回答