Introduction

This is part 3 and final part in taking a cloud application and transform it into a completely offline solution, running locally.

SSL Certificates

To record a language, the speaker needs access to the device microphone, which for modern browsers requires the website to have SSL certificates.

Given the web platform uses Cloudflare, we only had access to download the origin certificate so we chose to generate our own SSL certificates. This threw an insecure warning on Chrome, given the self-signed certificates are not by a reputable authority, but given the solution is offline anyway was deemed ok and people can bypass it by accepting the warning and proceeding to the site.

During the build and solution timeframe, a new requirement was dropped. The NUC was going to be placed in schools or government centres to be enable more people to interact with the platform. The new requirement meant that personal devices were no longer just accessing the platform, I had to now cater to managed devices as well.

The difference meant that given a central IT managing the security policies, we could no longer rely on the user accepting the insecure warning and proceeding to the website. As a result, this meant that the self-signed certificate currently used, could no longer be used.

In an offline solution, the devices are unable to be proxied by CDN’s such as Cloudflare nor be able to renewed every 90 days like let’s encrypt. The first attempt was to take the existing platform root certificates and mount them into docker. The theory we were looking to test was whether we needed the entire chain of trust certificates or simply just the root certificate given the completely offline nature of the environment. While not entirely unexpected, this didn’t work and the error still remained.

While less than ideal, the next solution was to buy an SSL certificate for a subdomain on the existing web platform. We entered the DNS record into the existing platform and once approved, downloaded and mounted the entire chain of trust certificates into Docker to verify the platform.

Initially much to my surprise this did not work. The error still remained. All information was on the certificate shown in Chrome but the insecure and invalid certificate warning was thrown.

After much research, debugging, trying listing the certificates in different orders and re-downloading, the final solution which worked was to clear out the SSL cache on NGINX.

Voila! As a result, we now had a completely offline solution with no insecure internet warning and securely accessed via personal and managed devices to help our First Nation communities record their languages.

Thanks for following along!