Use easy-rsa to set up a self-signed certificate authority for Central

I have spent a whole day googling not to understand this:

Generate appropriate fullchain.pem (-out) and privkey.pem (-keyout) files.

Says the ODK Doc. Now I have ca.crt, ca.key, myform.key and myform.crt, and I know how to convert these to pem and concatenate private and public. But I am lost why I need fullchain.pem (contains private+public) and privkey.pem(private of what)?

It looks like you're following the custom SSL certificate instructions, right? The private key is used by your server to decrypt data sent to it. Anyone with the public key can encrypt data for your server and it's critical that you keep the private key safe so that only your server can decrypt what is intended for it.

The fullchain.pem file should contain the full chain of server certificates. This includes your server's certificate and intermediate certificates that provide a trust chain between your certificate and a root certificate authority. Your certificate contains your public key but your private key should not be included in any file other than privkey.pem. Clients of your server will use that certificate chain to determine whether they trust your server. They will use the public key in your server's certificate to encrypt communications that your server will decrypt with the private key.

2 Likes

Thanks for the theory, in practice it was not so easy because the naming conventions are a horror.

And the most important part is that the privekey.pem cannot have a password, and easyrsa enforces having a password. Many thanks to user1686 on superuser!

1 Like

It sounds like you have been setting up your own Certificate Authority for local use, is that right? I've split out the thread to help direct anyone who might be looking for this kind of information since it's not the only way to use a self-signed cert.

It would be great to get an update on how you distribute your Certificate Authority's root certificate to your devices and get all the pieces working together.

I feel like this thread does need a disclaimer that this is only for advanced users who understand the ins and outs of SSL certificates. It's fairly easy to end up with a local system that appears secure but is easily exploitable.

EDIT: Or perhaps I've misunderstood and you're planning on using the certificate authority certificate as the certificate for Central?

Or perhaps I've misunderstood and you're planning on using the certificate authority certificate as the certificate for Central?

(to be accurate: certificate for an Intranet-Installatin of Central): First step. This works after I solved the naming problem and removed the password of the certificate.

Second step: Get the certificate on the Android Tablets. Seemingly easy in Chrome, but requires a login screen on the device (ok), and you will never get rid of the warning in the login screen "Your device is being watch by a third party" (Translation from German). This is not so nice, because it will scarce the security advisers in clinical context. Strange that it is easy to setup a cloud solution, but this is not acceptable for clinical data.

Third step (in work): On the Android device, I need an entry in the hosts file such as

192.168.2.31 sg.forms

which is not possible even with adb/usb because the file is read-only on my device. You will find some people on the net who had success. The alternative solution is to jail-break the device, which voids updates and again is not acceptable to the authorities. Maybe I can find a solution with jail-break and only giving access to the devices to one address via router. Which anyway would not be bad to avoid patients filling in the questionnaire play facebook or (Trump forbid!) TikTok.

Maybe a local nameserver is required - I have not looked into that yet.

Since I anyway have to document the whole procedure, I will post it when (or should I say if?) I am successful. There will be some compromises required.

I believe there are at least several projects that could use some more help with the "custom ssl" option. In my case, I am trying to design a configuration of odk-central that will support wireless clients but work without an internet connection. May I suggest that you describe one or more use cases that the "custom ssl" option was designed to enable, and describe how to setup the "custom ssl" to support the use case. I read above that this option is "only for advanced users..", but this information would be useful to those of us who are sketching out solutions to problems to find out if an "advanced user" could help us.

Best check these:

And the the official comment that self-signed certificates are not tested, so you are on your own:

2 Likes