Also have you tried to use a lets encrypt free SSL certificate?
-----Original Message----- From: Rene Veerman <[email protected]> Sent: Tuesday, 13 August 2019 06:13 To: [email protected] Subject: Re: running couchdb on a .app domain (https enforced) ok, i followed your instructions to the letter, Joan. and with a self-signed key, i'm now stuck at ERR_CONNECTION_REFUSED when connecting to the domain name. and i'm getting the same error when trying to connect to localhost:5984, and even to 127.0.0.1, same error. could it be that Google (who run the .app TLD) enforces a real certificate? like the one i used on regular apache on the same machine? problem is, i can't find any step by step guide to get me to that key_file, cert_file, cacert_file setup... :( and anyone who's not an expert at this sorta thing is probably going to run into the same problems. a couchdb installer that fails to ask for the simple files provided by domain registrars (where you buy the certificate for a .app domain) that are also fed to the regular apache daemon to make regular https to the webserver work. normally you'd google yourself through that, like i did with apache itself, but here the online documentation is also quite lacking. i don't want to look a gift horse in the mouth of course, i'm a programmer myself, and i hate documentation work like the next guy, but in this case, couchdb programmers, we could use at least a simple setup article (mentioned in the documentation, website, and installer for couch), and then later or even straight away, that input request in the couchdb installer. it sucks to have to remember the ins and outs of a OS sub system just to get it to work, and then go through the same difficult process of finding the right settings, when you need to re-install a machine a few months or years later. anyways, thanks for the help so far, people. but i'm still stuck, and would love some more good simple pointers. On Mon, Aug 12, 2019 at 7:48 PM Joan Touzet <[email protected]> wrote: > CouchDB with SSL has 2 ports for general access: 5984, and 6984. > > 5984 is the insecure http version of the port. You can't turn it off > easily in CouchDB 2.3.1, but you can change what port it appears at. I > recommend firewalling access to this port immediately. > > If you enable SSL, that'll be on port 6984 by default. You may have > changed it to port 7984. That's the one you want the world to see. It > shares the same address binding as the insecure 5984 port, so you must > bind both to 0.0.0.0 to see this externally. > > Do *not* change the settings for the administrative port (5986). Leave > this bound only to 127.0.0.1. > > Since you're having so much trouble, I'll write up the settings you > need. The following has: > > * Standard (http) port bound to 0.0.0.0:1234 (*firewall this*!!) > * SSL (https) port bound to 0.0.0.0:5984 (this is the one you want) > * Administrative port bound only to 127.0.0.1:5986 > * **BE SURE TO RESTORE THE ORIGINAL DEFAULT.INI FILE WE SHIP FIRST.** > > After changing this file, kill all running CouchDB processes, then > restart CouchDB. > > ``` > [chttpd] > port = 1234 > bind_address = 0.0.0.0 > > [httpd] > port = 5986 > bind_address = 127.0.0.1 > > [ssl] > port = 5984 > key_file = YOUR PATH HERE > cert_file = YOUR CERT HERE > cacert_file = YOUR CACERT HERE > ``` > > > > On 2019-08-12 8:18, Adam Kocoloski wrote: > > This means something else is already listening on one of the ports > > that > CouchDB is trying to use. > > > > Adam > > > >> On Aug 12, 2019, at 3:24 AM, Rene Veerman <[email protected]> > wrote: > >> > >> eaddrinuse > > > >
