Listen I have used lets encrypt and im even using it on my shared hosting panel. What google is enforcing is the use of HTTPS that is what they are after you will not run into issues, only with out https will you run into error messages from the chrome browser.
Also note with lets encrypt you will need to setup a cron job to check the expiration of the certificate as the Lets Encrypt certificates expire every 90 days. But to be fair I haven’t had an issue with them expiring as there is the apache cert bot which with a simple one line bash script you can setup the cron job to check automatically and automatically renew the certs. Regards, Jonathan -----Original Message----- From: Rene Veerman <[email protected]> Sent: Tuesday, 13 August 2019 06:38 To: [email protected] Subject: Re: running couchdb on a .app domain (https enforced) 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 > > > > > > > >
