Describe the bug
When following the install instructions for setting up CHT Core Framework on localhost, restricted users cannot log in. The following error is given:
An SSL certificate error occurred when fetching the script.
Error bootstrapping DOMException: Failed to register a ServiceWorker for scope ('https://localhost/') with script ('https://localhost/service-worker.js'): An SSL certificate error occurred when fetching the script.

To Reproduce
Steps to reproduce the behavior:
medic-conf --url=https://medic:password@localhost --accept-self-signed-certs upload-app-settings backup-all-forms delete-all-forms upload-app-forms upload-collect-forms upload-contact-forms upload-resources upload-custom-translationsmedic-conf --url=https://medic:password@localhost --accept-self-signed-certs csv-to-docs upload-docsCHW, associated to Andrew Artisan, at place Test Health Facility) Expected behavior
Expect to log in as a restricted user.
Environment
Additional context
Workaround is to start Chrome from the command line with the --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost options, as per this site. If we aren't able to solve this quickly we should at least document the workaround in the meantime.
This issue may be related to failed tests seen in https://github.com/medic/cht-core/pull/5219#issuecomment-456569431
After using the workaround even an unrestricted user cannot log in with Chrome in regular mode, as seen below. It seems as though the workaround may need some undoing, likely because it allows an invalid certificate to be saved, which can't then be used in the browser's regular mode.

The favicon error is on initial load, the other two when clicking Login.
Looks like the certificate generated is not trusted by the browser. I would like to pick this up.
@herbertUG That'd be great. Let me know if I can help!
@herbertUG Is this something you're still working on? Any updates here?
Moved to 3.12.0 to free up engineers to work on 3.11.0.
I managed to get the most recent version of medic-os and haproxy running on Firefox by clicking through the warning screen but no luck with Chrome. I'll follow up with SRE.
For now the workaround is to use Firefox!
Adding this to the SRE support dashboard.
I think the fix is to add some an exception to the nginx config so it doesn't redirect from http -> https when on localhost. This will mean you can access http://localhost (without the "s") and ignore certificates altogether. This will need some testing to ensure the service worker is registered correctly (it should be because Chrome has an exception for localhost).
Another option would be to add an environment variable to control this but it'd be bad to accidentally leave it on in prod.
I've pushed up a new docker image that only contains http. Please do not distribute this image to the wider community, I'm worried about it accidentally being used in Production. I think if we see interest from outside app developers to have this localhost feature, that should be a Product-Team discussion and have some more thought around communicating and documenting security concerns.
This will need some testing to ensure the service worker is registered correctly (it should be because Chrome has an exception for localhost).
@newtewt Can you test the image locally for that scenario?
DockerHub image: medicmobile/medic-os:dev-UNSECURE-HTTP-ONLY
@Hareet this is in 3.12 currently. It'll be a little bit before I can have a look.
Per discussions in slack, we're gonna redo the solution as follows:
medicmobile/medic-os:dev-UNSECURE-HTTP-ONLYmedic-os - this should not be bespoke to internal Medic use, but be generic to anyone using medic-os. "easy" is up to the implementer, but should take into account that we want it involve as little set up as posssible so QA, core eng, app serv and general technical interested public can use it alike. See these steps for more info. As a proof of concept confirming the manual process, it works really well:
docker-compose on it
docker exec -it medic-os bash
root@ed93cdc11a10:/srv# curl -s -o server.pem http://local-ip.co/cert/server.pem
root@ed93cdc11a10:/srv# curl -s -o chain.pem http://local-ip.co/cert/chain.pem
root@ed93cdc11a10:/srv# cat server.pem chain.pem > /srv/settings/medic-core/nginx/private/default.crt
root@ed93cdc11a10:/srv# curl -s -o /srv/settings/medic-core/nginx/private/default.key http://local-ip.co/cert/server.key
root@ed93cdc11a10:/srv# /boot/svc-restart medic-core nginx
Debug: Service 'medic-core/nginx' exited with status 143
Info: Service 'medic-core/nginx' restarted successfully
Success: Finished restarting services in package 'medic-core'

Closing in favor of #7061 - lemme know if you have any concerns!
That's fine if it supersedes it, thanks!
Most helpful comment
Looks like the certificate generated is not trusted by the browser. I would like to pick this up.