After some debugging I finally found “weird” solutions to both errors.
As you had earlier pointed out, the ‘verification issue’ was brought about by a fatal dockerd crash which in turn kills and restarts the server. This seems to be an issue unique to virtualized hardware droplets running Ubuntu 18.* (at least in my case). Switching to Debian 9 resolved the issue.
On the other hand, the ‘connection refused error’ by instances installed on both remote servers and select local machines is caused by a ‘freeze/delay’ on the XMPP container as it tries to generate gpg keys before the service ports are readied. This creates an impression to the client that the server is yet to start/has failed. As you mention here:
Freshly created virtualized hardware droplets will most certainly have very low entropy which is a bottleneck for the desired cryptographic randomness required to generate gpg keys. The command below can be used to check the system entropy on linux distros.
cat /proc/sys/kernel/random/entropy_avail
Any value above 3000 should work. If you get a 38 like me , you’ll need an entropy boost. My solutionwas rng tools and havege, however, I’m not sure it’s the best idea considering a process involving encryption parameters should not be guided/‘helped’ so to say.
With that the server works like charm. I can make a point of sharing my documentation on setup if it helps.
I however have two more queries @daniele_athome
-
At what point does the android application encrypt the messages, is it before saving them to the phone’s database or after? In other words is it [text]>encrypt>save>send or [text]>save>encrypt>send ?
-
I tried testing the compiled app on an Infinix phone running android 7 and got a looping X509Certificate error on logcat when passing the dummy verification code. It however works perfectly with the beta.kontalk.net server. Could this be an undoing of not generating my own SSL? If so, will Letsencrypt suffice or do I actually need a commercial provide.
Keen to hear from you.
Thank you.