我正在云端（AWS）的Ubuntu 12.10服务器上运行Apache CouchDB实例（版本1.3.0）。我正在尝试在我的couchDB实例上运行SSL。
基本的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网站上测试设置时（通过测试链接：http://www.digicert.com/help/购买SSL证书的公司）我收到以下错误：
服务器未发送所需的中间证书。
购买SSL证书时，我从DigiCert获得了中间证书，并下载了DigiCert的根证书。
在couchDB的local.ini配置文件中，您可以将它们与以下配置字段一起使用：
verify_ssl_certificates = true
cacert_file = xxxx
我的问题是，我无法让这个工作，并尝试了所有可能的组合，以使其工作。这是我尝试过的：
以上所有内容都会在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_certificates，根证书和中间证书
我已经在线阅读了所有文档，没有任何帮助
先谢谢 安德鲁
答案 0 :(得分：4)
对于任何有兴趣的人，我们最终解决了这个问题：
似乎我们无法使用我们的中间证书使couchDB正常工作。
由于我们在AWS EC2实例上运行我们的couchDB服务器，我刚刚创建了一个ELB（Elastic Load Balancer）实例并将我的证书上传到ELB，然后在我的负载均衡器下添加了EC2实例并将我的DNS重新路由到了负载均衡器（在这里也使用Route53）。
然后我在couchDB上完全关闭了SSL，并将SSL握手交给了支持使用中间证书的负载均衡器。
这确实意味着ELB和couchDB之间的通信是不安全的，但对我们来说没问题。
这也意味着我们现在可以在ELB下添加更多的couchDB服务器以实现可扩展性，从而实现2鸟类解决方案。
您也可以使用Nginx执行相同的解决方案，但添加和管理ELB非常简单和稳定，因此我们选择了ELB解决方案。
答案 1 :(得分：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进程用户选择了证书：
# in the ssl cert directory
sudo chmod 600 ./*
sudo chown couchdb:couchdb ./*
然后重新启动服务器：
sudo /etc/init.d/couchdb restart
答案 2 :(得分：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_file AND verify_ssl_certificates = true。但是，如果满足这些条件，则会省略服务器密钥和证书！
我发现这已经被归档为错误COUCHDB-2028。请注意，该错误表明这已在版本1.7.0中得到解决，我认为该版本不存在。
我在2014-01-30发现了the fix was applied to the official CouchDB repository。不幸的是，官方修订历史并未显示修复，但通过git repo挖掘显示该修复程序首次在CouchDB 1.6.0中正式发布。
就我而言，我能够从源代码下载并编译和安装CouchDB 1.6.1。现在，上面的openssl命令显示了CouchDB服务器发送的4个证书链。我提供服务器密钥和证书，以及从Namecheap下载的CA捆绑包的cacert_file。 verify_ssl_certificates是假的。我测试过的所有浏览器都信任该网站，而且我的命令行工具正常运行，无需修复验证。