HTTPS on Kolibri

So, we want a server setup that can be available on the public internet, but will also be available if we loose ISP connection.
That being said, many people expect HTTPS for their browsers, and we would like to teach the practice of searching for valid HTTPS.
That being said, I’ve figured out how we can do HTTPS to some degree, but with how Kolibri’s Nginx files were configured, it is a little wonky to setup.

Here is a link to the docs I have for setting it up, at the moment. I would appreciate feedback about it if anyone has any.

1 Like

Hi @Moussac - welcome to the forums :slight_smile: That’s a really good idea to offer online connectivity and make it secure and encrypted.

It’s great to see that you’re off to the right start with kolibri-server, which was designed to make it easy to customize ports, host names etc. I can recommend to leave the installed configuration files on kolibri-server in place so you can update the package without any conflicts.

I think you could do this:

  1. Keep default Nginx configs for local non-encrypted network access on port 80 or 8080
  2. Add an extra Nginx proxy with an SSL layer, using the proxy_pass directive

You definitely need access to Kolibri without SSL: Because on your local network, quite likely you will have to access Kolibri with a host name that you cannot obtain an SSL certificate for.

For the second customized configuration, do this:

Add a new file /etc/nginx/sites-available/kolibri and use proxy_pass and SSL configuration. You can see a recipe (without SSL) here:

I recommend that you get it working without SSL firstly, just seeing that your proxy pass works with some custom domain. Once you have this working, you can add the SSL.

Please feel free to ask away! It sounds like a really great setup!

A note from @jredrejo: You can customize the port of kolibri-server as a debconf setting.

If I remember correctly, this is how:

echo "kolibri-server kolibri-server/port select 80" | sudo debconf-set-selections
sudo apt install kolibri-server -y

If you still meet the question during installation, try running DEBIAN_FRONTEND=noninteractive apt install kolibri-server -y.

This way, you potentially don’t have to touch any of the distributed configuration files of kolibri-server.

will also be available if we lose ISP connection

This will likely be your biggest challenge. We had a related thread about this over here:

I feel like it may be beneficial as it is similar to the docs, but I don’t know how to do it…
Could I get some support on how to redirect to HTTPS? I have done some of the reading on proxy_pass-ing to https, but I don’t seem to have success.

Also, what is the reason you prefer proxy_pass over just a redirect from some other port?
The redirect seems more common, but is there otherwise a particular reason for doing a proxy_pass?

My thanks, this has been implemented in to the script for Debian.
(Then Ubuntu after testing)

This might be an issue for setting up something on localhost, but if we are offline, we can kind of make out own internal internet.
So, wouldn’t we still be able to setup the Letsencrypt servers ourselves?
They are open-source, after all.

That won’t work, as you need to be a Certificate Authority (the final signature in the Chain of Trust) such that your certificate is pre-installed in operating systems and browsers. Otherwise, if you run the LetsEncrypt platform yourself, you will have to manually install your CA into all your clients for the issued certificate’s chain of trust to work. I don’t think that effort is worth it, when it’s – as you say – on an intranet that doesn’t really need encryption.

Ah yes, many options to read the same goal – this was my proposition, please feel free to ask:

  • *:80: You don’t have to do anything here: This is the Nginx configuration for a default server on port 80, open to your internal network and serving Kolibri with a non-modified version of kolibri-server's Nginx and UWSGI configuration.
  • Open to the internet, is configured with a proxy_pass to serve (the above Nginx host). This way, you can keep its configuration minimal! This is where you will put your SSL configuration.
  • - Configured with Nginx to redirect everything to (the above configuration), overrules *:80 because it’s a more specific rule. I think you may want to use a Firewall and some NATing in front of your server to bind external port 80 traffic to another internal port, such that “intranet Kolibri” can have *:80 in its entirety for your internal network.

If you have a firewall in front of your server, perhaps you can serve unencrypted HTTP as yourdomain:81 on the server and serve port 80 on your external interface (router?), using NAT to redirect it to <your>.<server>.<ip>.<address>:81.

For me, making Nginx configurations work, usually starts by making them work without SSL and then adding it afterwards, to have a manageable amount of configuration introduced step-by-step :slight_smile:

Perhaps this order can be of use?

  1. Use the normal installation of kolibri-server and select to listen on port 80 (as the default server), with nothing else configured on Nginx. See that http://yourhost:80 works and serves kolibri
  2. Create a new nginx server configuration in /etc/nginx/sites-available/yourhost.conf, listening on port 123 with a proxy_pass serving, check that http://yourhost:123 works in your browser
    • … oh and remember to symlink the configuration in /etc/nginx/sites-enabled/yourhost.conf and run sudo systemctl reload nginx every time you change something.
  3. Change yourhost.conf to serve your actual domain name, ensure that your DNS, NAT etc. works and you can access from outside. You don’t need port 80 for this to work.
  4. When you have Kolibri running through the proxy_pass and accessible with your domain, start introducing SSL.

Could I get some support on how to redirect to HTTPS? I have done some of the reading on proxy_pass-ing to https, but I don’t seem to have success.

proxy_pass is used to serve something from an internal socket or TCP port, so for instance a browser can go to http://blah:123 and Nginx then serves back without the browser seeing the difference, since the whole proxy mechanism is inside Nginx. Now, if you use a redirect, Nginx will send back an HTTP response “302 moved” and the browsers address would change in the address bar to the new location - http://blah:567. This is very useful when you want to force the browser to use HTTPS instead of HTTP.

I hope it helps – there are many ways to set this up.