SSL issue with Central on my internal network

I succeed installing central on my local machine with IP address on my LAN for testing purpose before deploying on my public server. I created a projetct, an app, an app user, upload form and media files and granted rights for the user.

I face a problem when i try to get the form list into collect.

Sale screen as here but I think for other reasons :

Is ther a way to disable ssl certification for lacal testing or a workaround to get a certiciate for my local server (without a domain name)

Thanks a lot

1 Like

@issa gave me the following info a while back that could be useful?

Central requires HTTPS to be secure, and that it expects the following path structure:

  • https://…/* serves the frontend files. there is no frontend server; in the docker-compose setup we just leverage the nginx ssl terminator to also serve the static files.
  • https://…/v1/* is a proxy to the backend api. (the backend service will wish to see the /v1/ at root)

the backend expectations can be adjusted by proxy rewrites; the frontend may require more work depending on what you wish to set up.


If it's just for testing purposes, you'll probably love using ngrok as described in Testing ODK Collect with a Custom Server and Self Signed Certs and Authentication.


Hello @mathieubossaert.
Could you share a tutorial or image or a description of how to install Central Server .
Best regards.

Hi @famador, here is a link to the documentation with tutorials and guidance:


hello, unfortunately not. I just follow the documentation,
from here because docker is already installed on my machine :

But I am stuck on ssl issue on my local machine. I did not have time to test @LN and @danbjoseph proposals since she answered me.

so the problem you have here is that you are on a local (192.168..) IP address. this means that Let's Encrypt cannot provide a valid SSL certificate for you.

your options are:

  1. set up a local certificate authority that secures your development machine, and install that certificate on your android device (hard, time-consuming)
  2. mess with Central's code to remove HTTPS checks and run everything insecure (not hard, but dangerous)
  3. reinstall Central using a public domain name as suggested in the documentation, rather than use a local IP address

Thank @issa that's it.
As far as I understand, I can install Central without https and access/manage it with firefox.
The https problem only impact the connection between phone and server.
So I will manage form submission through usb.

1 Like

I haven't installed through the Docker setup recently but I thought I could use ngrok for testing last time I did that. Is that not the case? Note that @mathieubossaert states he just wants to try things out locally before doing a real deployment.

You'll also find that certain Central actions aren't permitted such as downloading a submission CSV.

It sounds like @mathieubossaert doesn't need to do form submission for his testing so this isn't as important but I still wanted to follow up because I learned some things discussing with @issa and @Matthew_White.

Using ngrok does work when using the development environment (no Docker). One additional thing to note is that the config/default.json file in the backend folder will need to be modified. In env, domain will need to be set to the public ngrok address.

However, using ngrok is not possible with the Docker setup and that's why @issa detailed the three options above. The most practical is probably to get a throw-away domain name even for local testing (e.g. from so that you can get an SSL certificate.

I have the inverse problem to @mathieubossaert: Development works fine on a external HTTPS server, because no confidential data are transmitted. But when I have to get it to work on a local server in a clinic or nursing home, I am lost, because no access to the outside world is permitted, ngrok or some letsencrypt solution therefore are not possible. So the only solution I see is to install a local CA.

  • Has anybody been able to get this to work reliably when it is not in a development setting with daily supervision?
  • I read in the docs :

Submission data is sent encrypted, even if Central is not configured with HTTPS.

Confused: Encryption is not required in an Intranet-installation, but I thought HTTPS was a requirement?

I am currently running two versions of certificates with one residing on a VPS server and one on the local server with ODK Central installed on a VM.

The VPS server is linked through VPN to another Ubuntu VM to provide access to my local servers including ODK Central.

So, I can access ODK Central either by resolving locally to the local IP address where the ODK central is installed or externally via the VPS public IP address linking back to the ODK Central by using Caddy.

Certificate wise, Caddy provides automatic renewal of Let's Encrypt SSL certificate which works if you are accessing outside the local network

Fortunately, I am running OPNsense (similar to PfSense) on my local network.
I simply issue a Let's Encrypt certificate for the same domain name that I use to resolve to Central externally on OPNsense. Then, I converted the issued certificates from OPNsense to the appropriate files and used the customssl guide by following this link.

For your case, I believe installing an open source firewall like PfSense can help you with managing the local servers. If your target is local access only then PfSense is an option because you can limit the outward facing interface to PfSense only which it can definitely generate the Let's Encrypt certificates.

The only downside to this approach is that you have to manually replace the certificates just before it expires during downtime of the ODK Central. If anyone knows of a better solution, I would gladly be open for any improvements to this approach.

1 Like

Thanks for you ideas. As far I understand, I have to install PfSense on a separate computer, or alternatively install ODK on a virtual machine. The first is not possible in my case - I only have a separated MiniServer with Ubuntu, which is running in a Windows domain.

I also do not fully understand the advantage compoare to minica: The greatest hurdle, having to install certificates on the clients, is the same. Or did I incorrectly read your last paragraph?

The documentation page you link to is about an optional encryption feature which encrypts each individual submission at rest. This is not typically necessary unless you can't trust the server that Central is installed on or the people who have access to that server. This feature ensures that only someone with knowledge of the encryption passphrase can access the data so even if someone gets direct access to the server's database or pulls submissions from the API, they can't do anything with them.

I realize that there is some introductory context missing on that documentation page and have filed an issue to add it at