The Nextcloud Talk client for Sailfish OS thread

Applications
#21

If you got a certificate from your ISP (internet service provider?) i think you did not get a ‘self signed’ certificate.
On a ‘self signed’ certificate the issuer and the owner name is the same.
If you take a look on the ssl certificate of the forum you got the following information:
Issuer: R3 (from organisation “Let’s Encrypt”)
Owner: forum.sailfishos.org
If your certificate did not have the same issuer and owner, you have to go up the certificate chain to the ‘root’ certificate (this is a ‘self signed’ certificate) and put this one to the phones certificate store.
You have to trust the ‘root’ certificate (the first one of the certificate chain) :wink:.

On the example above you have:
… … forum.sailfishos.org certificate ← ssl certificate
… … … Issuer: R3 (organisation “Let’s Encrypt”)
… … … Owner: forum.sailfishos.org
… R3 certificate ← intermedia certificate
… … Issuer: ISRG Root X1 (organisation “Internet Security Research Group”)
… … Owner: R3 (from organisation “Let’s Encrypt”)
ISRG Root X1 certificate ← this is a ‘self signed’ certificate (also known as ‘root’ certificate :wink:
… Issuer: ISRG Root X1 (organisation “Internet Security Research Group”)
… Owner: ISRG Root X1 (organisation “Internet Security Research Group”)

So at this example here you have to get the ‘ISRG Root X1’ certificate and put it on the certificate store of the phone.
I hope this help :wink:

1 Like
#22

Thank you very much for the detailed explanation. It was indeed like you described, I wasn’t used a ‘self signed’ certificate. I tried with the root certificate, but unfortunately still no luck. Nextcloud Talk Sailfish App still fails on verifying the host. I will try to change the code to bypass the ssl verification.

#23

How did you do that? Thank you!

#24

Matterbridge integration comes with NC Talk.

You can also run a separate matterbridge daemon and connect it to talk.

[EDIT:] PSA: I have just discovered that this functionality might put the bridge configuration file into /tmp/bridge-foo.toml, using the default web server umask. Which means here your bridge passwords may be stored in plain text in a world-readable file. NOT ok. Very much NOT ok. You can mitigate it a little by applying this change in case your NC version doesn’t have it.

1 Like
#26

Note that unless you solve the ssl verification problem, other software which talks to that server will have the same issue. It’s probably better to solve it at the root cause instead of working around in a single app.

#27

You are right, but I am not able to. I tried with the certificate, it doesn’t work. Do you think it worth to try to self sign SSL certificate with openssl? Will it be better than the one that I got from the ISP? Thank you!

#28

That is probably best discussed in a separate topic.

#29

Post the how to :slight_smile: Point to the how to:)

Ah, of course you did :wink: And matterbridge. Ok. I had that, sort of, working for xmpp → matrix. The question: do you have bi-directional communication running and if so, stuff like room discovery?

#30

And, sorry: RTFM. The connection is channel per channel.

EDIT:

They say they have/had (?) issues with xmpp. This is my currently working matrix<->xmpp bridge fragment:

[matrix.mymatrix]
Server="https://matrix.hostname.org"

#Use a dedicated user for this and not your own!
Login="xmpp"
Password="PASSWORD1"
RemoteNickFormat="[{PROTOCOL}] <{NICK}> "
NoHomeServerSuffix=false

[xmpp.myxmpp]
Server="xmpp.hostname.org:5222"
#Jid your userid
Jid="USER@hostname.org"
Password="PASSWORD2"
Muc="conference.hostname.org"
Nick="matrix"
RemoteNickFormat="<{NICK}> "

[[gateway]]
name="gateway1"
enable=true

[[gateway.inout]]
account="matrix.mymatrix"
channel="!blah:matrix.hostname.org"

[[gateway.inout]]
account="xmpp.myxmpp"
channel="aChannel"
1 Like
#31

If you look at the code, you should find the place where Nextcloud Talk search for valid (root) certificates. When you find it, you can place your ‘root’ certificate there.
May by Nextcloud did not look into phones ‘global’ certificate store (each linux system have it’s own way to create it - e.g. my debian have an other way as a SuSE :crazy_face:).
I found that on my Linux Nextcloud Client, my ‘own root certificate’ was stored at the user configuration ($HOME/~/.config/Nextcloud/nextcloud.cfg).
This was done automatically during the configuration of the connection.
BTW.: On configuration of the Linux Network Client i can allow untrusted certificates.

1 Like
#32

I thought in Sailfish Os, the certificate is stored on /home/nemo/.mozilla/mozembed/…

1 Like
#33

Can any of the 4.4EA testers comment on whether Talk works in sailjail?

1 Like
#34

I just tried to launch it, it lost the configuration. I’ll try to migrate it manually to the new path to see if that works

#35

Thanks.
I have a PR open which seems to make it work, but it needs some careful review because the Secrets permission makes it incompatible with older SFOS versions.

#36

For some reason it completely lost the configuration (directory .config/harbour-nextcloud-talk is empty), or i am looking in the wrong place (there is still data in .local/share). I need to reconfigure everything to test further.

#37

.config isn’t used by nextcloud talk. If you’re seeing an empty window it’s because the program can’t access the secrets daemon.

The directory is very likely created by sailjail in compatability mode as a mount point.

#38

A Sailjail compatible release is out:

1 Like
#39

Ok it seems the app has some problems. Not sure it’s related to 4.5.0.16 or something else.
So the problem is related to Sailfish Secrets DB.
It can’t just read out freshly stored secrets.
NextCloud Talk reports this:

“Unable to decrypt collection nextcloudTalk with the entered authentication key”

I’m not sure how to handle this. Maybe I should just remove the Sailfish Secrets DB file from somewhere so it’s totally fresh now?

#40

I can confirm it does work in 4.4 so maybe it is indeed 4.5.

#41

would be good to get some details what changed then.