0

I'm currently trying to get my CouchDb installation up and running with a SSL certificate. My configuration is as follows:

[ssl]
port = 6984
enable = true
cert_file = /ssl/bws2020.crt
key_file = /ssl/bws2020.key
;password = N3sHfhgV4
; set to true to validate peer certificates
;verify_ssl_certificates = false
; Set to true to fail if the client does not send a certificate. Only used if verify_ssl_certificates is true.
;fail_if_no_peer_cert = false
; Path to file containing PEM encoded CA certificates (trusted
; certificates used for verifying a peer certificate). May be omitted if
; you do not want to verify the peer.
;cacert_file = /full/path/to/cacertf
; The verification fun (optional) if not specified, the default
; verification fun will be used.
;verify_fun = {Module, VerifyFun}
; maximum peer certificate depth
;ssl_certificate_max_depth = 1

After restarting the CouchDb instance I can still access the service through regular HTTP, but when I try using HTTPS it just loads forever. If I open the log file I find the following entries:

2020-04-22T09:02:52Z couchdb.server[55847]: [error] 2020-04-22T09:02:52.403204Z couchdb@127.0.0.1 <0.29802.2065> -------- application: mochiweb, "Accept failed error", "{error,{options,{certfile,\"/ssl/bws2020.crt\",{error,enoent}}}}"
2020-04-22T09:02:52Z couchdb.server[55847]: [error] 2020-04-22T09:02:52.404265Z couchdb@127.0.0.1 <0.29802.2065> -------- CRASH REPORT Process  (<0.29802.2065>) with 0 neighbors exited with reason: {error,accept_failed} at mochiweb_acceptor:init/4(line:75) <= proc_lib:init_p_do_apply/3(line:247); initial_call: {mochiweb_acceptor,init,['Argument__1','Argument__2',...]}, ancestors: [https,couch_secondary_services,couch_sup,<0.212.0>], messages: [], links: [<0.261.0>], dictionary: [], trap_exit: false, status: running, heap_size: 1598, stack_size: 27, reductions: 1041
2020-04-22T09:02:52Z couchdb.server[55847]: [error] 2020-04-22T09:02:52.414818Z couchdb@127.0.0.1 <0.30525.2065> -------- application: mochiweb, "Accept failed error", "{error,{options,{certfile,\"/ssl/bws2020.crt\",{error,enoent}}}}"
2020-04-22T09:02:52Z couchdb.server[55847]: [error] 2020-04-22T09:02:52.415121Z couchdb@127.0.0.1 <0.30525.2065> -------- CRASH REPORT Process  (<0.30525.2065>) with 0 neighbors exited with reason: {error,accept_failed} at mochiweb_acceptor:init/4(line:75) <= proc_lib:init_p_do_apply/3(line:247); initial_call: {mochiweb_acceptor,init,['Argument__1','Argument__2',...]}, ancestors: [https,couch_secondary_services,couch_sup,<0.212.0>], messages: [], links: [<0.261.0>], dictionary: [], trap_exit: false, status: running, heap_size: 1598, stack_size: 27, reductions: 1041

If I understand the logs correctly it means that it cannot find the certificate file. However I have verified the path multiple times and even chmod'ed the certificate and key files to 777, but the issue remains.

We are using CouchDb 2.3.1 on Ubuntu Server 18.04.

Can someone help me understand what causes this error?

The /ssl folder looks like this:

root@couchdb-s1:~# ls -la /ssl
total 28
drwxrwxrwx  2 root root 4096 Apr 23 09:13 .
drwxr-xr-x 24 root root 4096 Apr 29 06:09 ..
-rwxrwxrwx  1 root root 2618 Mar 10 12:12 bws2020.crt
-rwxrwxrwx  1 root root 2108 Mar 10 12:12 bws2020.key
-rwxrwxrwx  1 root root 1310 Apr 23 09:13 self.crt
-rw-r--r--  1 root root 1050 Apr 23 09:13 self.csr
-rwxrwxrwx  1 root root 1675 Apr 23 09:09 self.key
Thomas Boulund
  • 1
  • 1
  • can you share your output of `ls -la /ssl` – Jan Lehnardt May 01 '20 at 19:00
  • Sure, I have added the information to the original question :) – Thomas Boulund May 04 '20 at 09:15
  • ah, there is a mismatch between your config and the error log. config says `self.{crt,key}` but logs say `bws2020.{crt,key}`. of course, given this `ls -la` it shouldn’t make much of a difference, but can you update the config and logs to match? – Jan Lehnardt May 05 '20 at 10:33
  • You're right - the self signed certificate was just for debugging the issue. I have updated the question, but the problem remains :) – Thomas Boulund May 05 '20 at 11:53
  • one more possibility: if you copy and pasted the file values into the ini file, there might be some non-printable ascii characters in there that don’t show up anywhere – Jan Lehnardt May 06 '20 at 12:55

0 Answers0