Apache CouchDB CA签名证书问题

Question

我正在云中的Ubuntu12.10服务器（AWS）上运行一个Apache CouchDB实例（1.3.0版）。我正在尝试让SSL在我的couchDB实例上工作。

基本的SSL设置非常简单。我已将我的证书和密钥放在一个目录中，并在我的本地应用程序中取消了以下行的注释。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. 已尝试从DigiCert将cacert_文件设置为中间证书

以上所有操作都会在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:

有人知道如何在couchDB中正确使用verify_ssl_证书、根证书和中间证书吗

我在网上看了所有的留档没有任何帮助

提前感谢Andrew

Answer 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可以作为“cacertfile”传递一个PEM文件。这既用于验证客户端证书（如果启用），也用于在TLS证书消息中组成要发送给客户端的完整证书链。然而，我的CouchDB版本没有传递cacertfile参数，除非指定了cacert\u文件和verify\u ssl\u certificates=true。但是，如果满足这些条件，它将忽略服务器密钥和证书！

我发现这已经被归档为bug COUCHDB-2028。请注意，bug说这已经在1.7.0版本中得到解决，我相信这是不存在的。

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

在我的例子中，我能够从源代码下载、编译并安装CouchDB 1.6.1。现在，上面的openssl命令显示了CouchDB服务器发送的4个证书链。我提供服务器密钥和证书，以及从Namecheap下载的CA包的cacert_文件<代码>验证ssl证书为假。我测试过的所有浏览器都信任该网站，加上我的命令行工具在没有黑客攻击的情况下可以禁用验证。

Answer 2

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时，请跳过服务器的内容。将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进程用户对证书进行检查：

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

然后重新启动服务器：

sudo /etc/init.d/couchdb restart

Answer 3

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

似乎我们无法让couchDB使用我们的中级证书正常工作。

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

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

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

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

你也可以用Nginx做同样的解决方案，但是添加和管理ELB很容易也很稳定，所以我们使用了ELB解决方案。