Apache couchDB CA签名证书问题

我正在云中的Ubuntu12.10服务器（AWS）上运行ApacheCouchDB实例（版本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服务器启动，您可以毫无问题地导航到

使用openssl进行测试

openssl s_client -showcerts -connect mycouchdbserver.com:443

提供标准SSL配置的正确结果

在DigiCert网站（该公司通过-test link:购买SSL证书）上测试设置时，我遇到以下错误：

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

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

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

verify_ssl_certificates = true
cacert_file = xxxx

我的问题是，我不能让这个工作，并已尝试了每一个可能的组合，使这个工作。以下是我尝试过的：

已尝试将cacert\u文件设置为来自DigiCert的中间证书

已尝试将cacert\u文件设置为/etc/ssl/certs中的根证书

尝试将DigiCert网站的根证书添加到/usr/shared/ca certs/，然后运行dpkg重新配置ca证书以安装新的根证书，并在/etc/ssl/certs中将cacert_文件设置为新的pem编码证书

已尝试将证书和中间证书合并到用于证书文件的一个文件中

已尝试将证书、中间证书和根证书组合到用于证书文件的1个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:

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

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

提前谢谢

---

安德鲁

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

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

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

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

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

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

---

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

CouchDB对一些事情很敏感。一个问题是Name便宜的重新发行表格。如果您使用namecheap处理您的CSR，您将遇到问题。例如，我通过Namecheap购买了一个RapidSSL证书，为了正确地重新颁发，我必须直接到GeoTrust获得一个有效的证书：

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

$ openssl genrsa -des3 -out server.pem 2048

使用了密码短语。它必须用于其他命令别忘了它

创建证书请求：

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

只回答以下问题：

$ openssl genrsa -des3 -out server.pem 2048

• 国家
• 陈述
• 地点
• 组织机构
• 通用名

所有其他问题都留白了

此命令创建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进程用户对证书进行检查：

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

然后重新启动服务器：

sudo /etc/init.d/couchdb restart

---

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

我在运行CouchDB 1.4.0或Raspberry Pi（raspbian jessie）时也遇到同样的问题

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

openssl s_client -connect myhostname:6984 -showcerts

这只显示了一个证书。此外，它报告了一次核查失败。我的证书是从美国来的。虽然我在客户机上安装了颁发者的根证书（COMODO RSA），但至少需要一个中间证书来完成链

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

在深入研究CouchDB和Erlang源代码之后，我发现了以下内容： Erlang可以作为“cacertfile”传递一个PEM文件。这两种方法都使用