since slack is an IRC setup, not a mailinglist, i'll continue to fill in
details of my efforts here..
i have the following files, the cc*.* and gd*.* are provided by my domain
registrar after buying the https certificate for plain apache https there...
the nicer.app--*.* files i also got at the same time.
the rest are either the result of following the instructions (listed
earlier in this email thread) to generate a self-signed key (server.key,
server.crt, server.csr) or my latest attempt to use the domain registrar
provided files per the same instructions found earlier..
root@albatross:/opt/couchdb/etc/https# ls
cc32e1610b674c2e.crt gd_bundle-g2-g1.crt
nicer.app--generated-private-key.txt server.csr
cc32e1610b674c2e.pem nicer.app--generated-csr.txt server.crt
server.key
root@albatross:/opt/couchdb/etc/https# openssl req -new -key
nicer.app--generated-private-key.txt -out server-nicer.app.csr
unable to load Private Key
140197654409664:error:0909006C:PEM routines:get_name:no start
line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY
root@albatross:/opt/couchdb/etc/https# openssl req -new -key
cc32e1610b674c2e.crt -out server-nicer.app.csr
unable to load Private Key
140390305173952:error:0909006C:PEM routines:get_name:no start
line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY
On Tue, Aug 13, 2019 at 7:34 AM Rene Veerman <[email protected]>
wrote:
> ok :)
>
> On Tue, Aug 13, 2019 at 7:33 AM Joan Touzet <[email protected]> wrote:
>
>> The other link I sent is way better :D
>>
>> On 2019-08-13 1:32 a.m., Rene Veerman wrote:
>> > never mind, found it.. :)
>> >
>> https://mail-archives.apache.org/mod_mbox/couchdb-user/201908.mbox/browser
>> >
>> > On Tue, Aug 13, 2019 at 7:24 AM Rene Veerman <[email protected]>
>> > wrote:
>> >
>> >> ok Joan, thanks for your help.
>> >>
>> >> one final question : is this email list we're using here archived on
>> the
>> >> web anywhere? if so, where?
>> >>
>> >> On Tue, Aug 13, 2019 at 7:19 AM Joan Touzet <[email protected]> wrote:
>> >>
>> >>> It doesn't look like CouchDB is listening on port 5984 at all if it's
>> >>> refusing any connections there.
>> >>>
>> >>> Sorry, I'm out of ideas. I recommend you hop on the CouchDB Slack
>> >>> (instructions at https://couchdb.apache.org/) and get some real-time
>> >>> help.
>> >>>
>> >>> On 2019-08-13 12:41 a.m., Rene Veerman wrote:
>> >>>> total disobedience ;)
>> >>>>
>> >>>> root@albatross:/opt/couchdb/etc# curl --verbose
>> http://localhost:5984/
>> >>>> * Trying 127.0.0.1...
>> >>>> * TCP_NODELAY set
>> >>>> * connect to 127.0.0.1 port 5984 failed: Connection refused
>> >>>> * Failed to connect to localhost port 5984: Connection refused
>> >>>> * Closing connection 0
>> >>>> curl: (7) Failed to connect to localhost port 5984: Connection
>> refused
>> >>>> root@albatross:/opt/couchdb/etc# curl --verbose
>> https://localhost:5984/
>> >>>> * Trying 127.0.0.1...
>> >>>> * TCP_NODELAY set
>> >>>> * connect to 127.0.0.1 port 5984 failed: Connection refused
>> >>>> * Failed to connect to localhost port 5984: Connection refused
>> >>>> * Closing connection 0
>> >>>> curl: (7) Failed to connect to localhost port 5984: Connection
>> refused
>> >>>> root@albatross:/opt/couchdb/etc#
>> >>>>
>> >>>> On Tue, Aug 13, 2019 at 6:40 AM Joan Touzet <[email protected]>
>> wrote:
>> >>>>
>> >>>>> What output do you get for:
>> >>>>>
>> >>>>> curl --verbose http://localhost:5984/
>> >>>>>
>> >>>>> curl --verbose https://localhost:5984/
>> >>>>>
>> >>>>> Let's get that working first before we try and sort out whatever the
>> >>>>> heck is going on with .app domains.
>> >>>>>
>> >>>>> -Joan
>> >>>>>
>> >>>>> On 2019-08-13 12:38 a.m., Rene Veerman wrote:
>> >>>>>> and the log :
>> >>>>>>
>> >>>>>> root@albatross:/opt/couchdb/etc# rm /var/log/couchdb/couchdb.log
>> >>>>>> root@albatross:/opt/couchdb/etc# service couchdb restart
>> >>>>>> root@albatross:/opt/couchdb/etc# cat /var/log/couchdb/couchdb.log
>> >>>>>> [info] 2019-08-13T04:30:19.782183Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_log started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.784813Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application folsom started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.809271Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_stats started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.809378Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application khash started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.813194Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_event started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.813291Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application hyper started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.816832Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application ibrowse started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.819801Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application ioq started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.819931Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application mochiweb started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.824769Z [email protected] <0.212.0>
>> >>> --------
>> >>>>>> Apache CouchDB 2.3.1 is starting.
>> >>>>>>
>> >>>>>> [info] 2019-08-13T04:30:19.824829Z [email protected] <0.213.0>
>> >>> --------
>> >>>>>> Starting couch_sup
>> >>>>>> [notice] 2019-08-13T04:30:19.830479Z [email protected] <0.96.0>
>> >>> --------
>> >>>>>> config: [features] pluggable-storage-engines set to true for reason
>> >>> nil
>> >>>>>> [info] 2019-08-13T04:30:19.889337Z [email protected] <0.212.0>
>> >>> --------
>> >>>>>> Apache CouchDB has started. Time to relax.
>> >>>>>>
>> >>>>>> [info] 2019-08-13T04:30:19.889419Z [email protected] <0.212.0>
>> >>> --------
>> >>>>>> Apache CouchDB has started on http://127.0.0.1:5986/
>> >>>>>> [info] 2019-08-13T04:30:19.889518Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.889624Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application ets_lru started on node '[email protected]'
>> >>>>>> [notice] 2019-08-13T04:30:19.909310Z [email protected] <0.276.0>
>> >>>>> --------
>> >>>>>> rexi_server : started servers
>> >>>>>> [notice] 2019-08-13T04:30:19.911977Z [email protected] <0.280.0>
>> >>>>> --------
>> >>>>>> rexi_buffer : started servers
>> >>>>>> [info] 2019-08-13T04:30:19.912108Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application rexi started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.933416Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application mem3 started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.933443Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application fabric started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.943825Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application chttpd started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.950696Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_index started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.950722Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_mrview started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.950809Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_plugins started on node '[email protected]'
>> >>>>>> [notice] 2019-08-13T04:30:19.980249Z [email protected] <0.96.0>
>> >>> --------
>> >>>>>> config: [features] scheduler set to true for reason nil
>> >>>>>> [info] 2019-08-13T04:30:19.990117Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_replicator started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:19.994567Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application couch_peruser started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.001778Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application ddoc_cache started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.010320Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application global_changes started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.010341Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application jiffy started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.013833Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application mango started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.017261Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application setup started on node '[email protected]'
>> >>>>>> [info] 2019-08-13T04:30:20.017321Z [email protected] <0.9.0>
>> --------
>> >>>>>> Application snappy started on node '[email protected]'
>> >>>>>> root@albatross:/opt/couchdb/etc#
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Aug 13, 2019 at 6:38 AM Rene Veerman <
>> [email protected]
>> >>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> included below here is the log of restarting couchdb, it looks
>> >>>>> completely
>> >>>>>>> normal to me.
>> >>>>>>> i've included it so others won't have to guess what's in it.
>> >>>>>>>
>> >>>>>>> and yeah, when i bought the .app domain, they didn't mention
>> enforced
>> >>>>>>> https.
>> >>>>>>> but hey, lets just update the docs and make this simple, shall we?
>> >>>>>>> coz it seems according to the article posted by Jonathan just now,
>> >>>>>>> that this is an encroaching "problem".
>> >>>>>>>
>> >>>>>>> and probably a non-problem for someone skilled at crypto setups on
>> >>>>> ubuntu.
>> >>>>>>>
>> >>>>>>> ehm, i'm hesitant to try out the lets encrypt service (
>> >>>>>>> https://letsencrypt.org/getting-started/ ),
>> >>>>>>> because i fear Google would enforce somehow, with another cryptic
>> >>>>> browser
>> >>>>>>> error,
>> >>>>>>> that i use the same certificate as for regular https traffic to
>> >>> apache
>> >>>>> on
>> >>>>>>> the same machine.
>> >>>>>>>
>> >>>>>>> and since my primary use for couchdb is AJAX access from the
>> browser
>> >>>>> with
>> >>>>>>> a javascript plugin,
>> >>>>>>> this could be a real stubborn problem if i try letsencrypt.
>> >>>>>>>
>> >>>>>>> i may try it out later, ok...
>> >>>>>>> i wanna get some coding work done too today.
>> >>>>>>>
>> >>>>>>> On Tue, Aug 13, 2019 at 6:25 AM Jonathan Aquilina <
>> >>>>> [email protected]>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> 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
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
