I've got a new local install and I'm using a customssl. We have an internal CA that I used to generate a certificate for this. The central server operates without any issues. The site cert is happy.
I made sure the full chain is included in the cert export. Any browser I test with is happy about the certificate.
The error is when I try to view a test form. I get this error: self signed certificate in certificate chain
I'm not quite sure what to do to try resolve this since everything else works great except viewing the form. Any advice? thanks
Enketo web forms and ODK Collect currently only support public CAs. This is something we might re-consider but it would open up ODK users to more risk. That means we'd want to take time to explore the consequences for our various users.
The fact that one must use a public CA and cloud server rises the opposite fear in highly critical clinical applications, where the server is internal and all external access is blocked by firewals for security reasons. Being forced to use a public certification and a public server is just the opposite of a secure environment - public servers in non-compliant countries such as the the US make it worse.
I am sympathetic to your case and I understand you work with a team of professionals who know how to configure firewalls and have experience managing private keys!
However, the challenge is that many of our users have limited technical capacity. By ensuring that everyone must use SSL and a public CA, we have relative assurance that most people have a secure setup. The concern is that if we allow self-signed certificates, they'll be used as the path of least resistance and lead to unsafe configurations. We've seen this in the field -- some users don't understand the implications and others use self-signed certificates and other problematic security practices in their test environments and then just use that environment for production.
I've consulted with some security professionals who have shared various opinions on the matter. I do at some point intend to make a proposal to rethink this policy but it's not clear when I'll have a chance to do that. If someone would also like to do some analysis on the implications of a policy change and what documentation would need to accompany it, that would be appreciated. It will be important to consider that current typical usage of ODK clients is for distributed data collection that cannot happen within a single network. A good first step is starting a Features thread. Descriptions of environments/scenarios where self-signed certs are desirable and safe are a good start.
We've got a requirement to use the enketo platform as well and that's where we fail with the self signed cert. I spent numerous hours working on the enketo ssl enforcement until I gave up realizing the changes I made will not be supportable in our deployment.
We had to leave this option behind and implement kobotoolbox instead. Their implementation allows for a Non-SSL environment and then we provide the SSL via proxy to secure the connections.
We're required by law to run our instances in our own datacenters so we are forced to use internal CA. I hope the teams finds a way to support these instances as we are just beginning our need for data collection tools like this in our public health space.
Where are you located? It would be very interesting to learn a little bit more about your datacenter setup and why it doesn't use a public CA. Am I understanding correctly that you will have public Enketo forms using a cert issued by an internal CA? Is cert provisioning a service from your datacenter with secure private key management, etc?
It looks like your requirements are the same as ours. We also started with Kobo, but the main reason why I stopped using it is the horrible documentation of the API - which is really good for ODK (kudos, whoever generated these, even I would have preferred Jagger).
After the mess of getting ODK to work in an Intranet setting, I am no longer sure this was the right decision. We need the API because the web-admins in both products are too nerdy for end-users. KOBO has a better workflow, and has some nice features such as event handling ("A new patient came in") which must be implemented on database level with ODK.