the past weeks we have gone through http/https/certificate nightmares with kobo-install and we still have not solved our problem.
Last year, we started with kobo-install using https and a Let’s encrypt certificate. Everything worked as expected. But without touching the system, one day, a certificate renewal request from the certbot service was rejected by Let’s encrypt, stating that we had made too many renewal requests in a too short time, so our certificates got blocked.
Then we tried using our own certificate (not self-signed) with kobo-install, so we chose “Use https” YES and “Use Let’s encrypt” No in the kobo-install setup-wizard, but the kobo containers would not startup (no errors, startup did just not finish) and we had no idea where to put our own certificates, so that the docker containers would find them.
Then - and this is our current solution - we told kobo-install to use http internally and use a https-reverse proxy in front. So we chose “Use https” NO and “Use a reverse proxy” YES.
We had to test a lot to geht this scenario working, because now we had a mix of https- and http-requests in our client/server-communication which most current browsers do not allow. But with some additional proxy-configuration we got it working.
BUT, now the problem is what @sheku_munu_kc describes in his/her post (Kobo form could not open): Now, the open button to open the enketo-form is not working and the copy button has disappeared.
This problem is not caused by the proxy, because accessing kobo via http directly (and not via the proxy) also shows the same problem. It seems to be a problem with using http in the kobo-install script.
Does anybody have similar problems? Can anybody help?
We are using the following docker image versions:
kobotoolbox/nginx latest kobotoolbox/kobocat 2.019.52-final-shared-database kobotoolbox/enketo-express-extra-widgets 1.77.0-jnm-grunt-workaround kobotoolbox/kpi 2.019.52-final-shared-database mongo 3.4 mdillon/postgis 9.5 redis 3.2
Thanks in advance,