CouchDB won't work over SSL

Question

I am running the CouchDB Docker container, V.2.1.1. Everything is working at this point except for SSL. I am following the CouchDB documentation on SSL setup. The container has OpenSSL 1.0.1t.

As shown in the documentation, I am using a self-signed certificate. When I try to connect to the SSL page on port 6984:

Chrome tells me

"ERR_CONNECTION_CLOSED".

curl gives me

curl -k https://localhost:6984

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

In the server log, I get a whole lot of this.

hello terminated with reason: no function clause matching ssl_cipher:hash_algorithm

A search on this last error turns up information indicating that the Erlang version has an issue. However, I believe the CouchDB container has an already patched version. I did try and upgrade with:

apt-get install Erlang

This made no difference. Search results also point to the version of OpenSSL having a problem. I upgraded to OpenSSL 1.1.1 from source, Recreated the certificates, and still, the issue persists.

As requested, here is the output from a few more commands.

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

The output from the following three commands is very similar. I will just show the differences. However, it seems that a handshake is now taking place with all of these commands.

$ 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"}}

So I am guessing there is a problem with the built-in version of LibreSSL? The next question is what can be done about it?

Answer 1

I can't say for sure that this is the actual answer to the particular problem the OP had some three years ago and counting, but here's AN answer — at least to what MY problem was when debugging that same error.

In my case, I was moving from macOS to Linux Mint, and by extension, from MacPorts and Homebrew to apt and less user-centric ways of handling software.

I say less user-centric, because the root of the problem stems from here. In particular, I had rsynced all my development and configuration files from my macOS system to this new Mint system, and being that the approach on my Mac was to run nginx, php-fpm, couchdb, etc. as me — that is to say, as daniel:staff, then my SSL certificates, found in ~/Projects/SSL were also owned by me.

And, because best practice is to lock down your certificates with a 0600 umask, and some applications refuse to run if they're not, my certificates were not readable by anyone but me, including the couchdb user which couchdb runs as by default on "properly configured" systems like Linux.

SSL_ERROR_SYSCALL does hint at this — at least, it hints to the error relating to a system call, as opposed to something with the certificate structure itself.

Also, we see No client certificate CA names sent, read 0 bytes, New, (NONE), Cipher is (NONE) and several more NONEs, all hinting to nothing actually being read.

Again, it MAY be that the OP's problem was different, but in my case, a simple chmod on the SSL files to allow couchdb to actually read them and not throw up here.

I'm continuing on to generate a new self-signed certificate and give it to couchdb explicitly, but anyway, this was the problem behind these errors on my particular box.

Answer 2

In order to dig deeper, can you post the output of the following commands?

$ 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

---

By the way, I notice that your curl is using LibreSSL not OpenSSL as indicated in the error message you're getting:

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:6984

---

When you try openssl:

$ openssl s_client -connect localhost:6984

You are getting this error:

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:

Can you please report the output of this command:

$ openssl s_client -tls1 -connect localhost:6984

Also, it might be inferred that the cause of the problem is your macOS default version of LibreSSL/OpenSSL. To fix the problem, try to install the brew version OpenSSL and run this command again, and please report the output:

$ path/to/brew/version/of/openssl s_client -connect localhost:6984

Also please post the output of this too:

$ path/to/brew/version/of/openssl s_client -tls1 -connect localhost:6984

---

Based on your reported outputs, please try the following command and see if it works:

$ curl -k --tlsv1 https://localhost:6984

Answer 3

If your SSL certificate is self-signed:

---

You didn't show your curl command, but I guess you are not using the -k option, but you should:

-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.