SSH by default

[crossan007]

I think this should [also | exclusively] listen on SSH by default with a self signed cert.

It'll throw some warnings at user's browsers, but it should be secure by default

What does docker have in the way of cert utilities?

[jaskipper]

Agreed. We can easily set it up to listen on SSH. We could include instructions for someone to install "Let's Encrypt" so that it wouldn't throw warnings.

[crossan007]

I love LE; however, that requires the docker image be internet-accessible at time of provision to generate the cert....

edit: someone else has done this already ;-) let's not reinvent the wheel

[crossan007]

http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/

[jaskipper]

Yes... We would have to live with the browser warnings, although we can still include instructions if someone is installing this on their web server

[jaskipper]

This is my next order of business

[jaskipper]

@crossan007 , I have pushed a new branch to update Docker to the newest released version of ChurchCRM. I will also work on having SSL's work w/ self-signed certificates. Let's Encrypt won't work on localhost. I just got SSL working on a different Docker project that I'm working with (using Nginx). It shouldn't be too difficult to do w/ Apache.

[crossan007]

Nice!! +1 for SSL

[jaskipper]

@crossan007 I've got SSL working, auto-installed when building the images... Of course, as they are self signed, browsers throw a warning on the first visit. One issue is that Chrome 65 always shows "Not Secure" in big red letters on the top. From what I can tell in my research, there's no way of getting around that now... unless you have a domain and certificate that has been authorized by a third party. This is the error: (net::ERR_CERT_AUTHORITY_INVALID). I'm pretty sure we would have to live with it unless you have a better idea.

[ajcollett]

Another side note. It may be worth having 2 or 3 versions of the system that can be run with multiple docker-compose files. "Production" which includes lets-encrypt, "development" which runs un-encrypted, and custom where a user can provide his cert file in a file...

[jaskipper]

Agreed @ajcollett, although it's not possible to run lets encrypt on a local system without a fully qualified domain name. I can see:

1. Local Production w/ cert file (the branch that I've uploaded actually creates that for the user)...
2. Remote Production w/ Lets-Encrypt under a fully qualified domain name.
3. Local Development unencrypted, downloading the latest release including RC's

[graememross]

I would like to agree with @ajcollett. In my case I have a docker image running in a kubernetes system. I am already SSL enabled, but the SSL connection is terminated at the kubernetes ingress, with kube-lego looking after the renewing of certificates from letsencrypt.

Having kube-lego manage the SSL certificates means that all of my sites are managed in one place.

If the docker container MUST have SSL terminated at the container this makes it difficult for me to manage.

[ajcollett]

I wonder if it would be easier to run a simple reverse proxy in a separate container, instead of having the main container require SSL. Then the sys-admin can decide if he want to link to the SSL container, or his own.

This will also mean less work for the maintainers, because ssl isn't a concern on the main app.

[graememross]

That is exactly the situation with kubernetes. The kubernetes ingres is a reverse proxy (nginx in my case) which handles all the entry points for everything in my cluster. All SSL configuration is concentrated at the proxy and I don't have to worry about the individual apps.

[jaskipper]

Great idea. That's exactly what we need to do. I'll set that up as well. Should be easy