Joplin does not trust Android certificate store?

[OdinVex]

Yet another “Network Request Failed” post. Joplin Android won't connect to local WebDAV, Desktops all do.

I use my own certificate authority in my domain behind my router with private DNS as well. I've installed my CA-certificate on all devices, including my Android devices. While some apps need to be told to use Android's certificate/security store to work (Firefox, for example), some automatically trust the Android CS store.

I use my CA to sign certificates, the chain included is served by the web server. Other devices, Linux/Windows, they all work, even without “Ignore TLS certificate errors”, but that doesn't work for Android. I believe it only ignores self-signed certificates, instead of TLS certificate errors (such as what I believe is happening, that Joplin isn't trusting it because it doesn't trust the CA or the Android CS store which does.)

Environment

Joplin version: 2.6.3 Platform: Android OS specifics: v7, v9

Steps to reproduce

1. Create a CA, import to all devices as trusted CA. Sign any intermediate/end certificates for use with a WebDAV server.
2. Point Joplin to a WebDAV.
3. Fail at synchronizing.

syncReport-1639758713530.txt

[OdinVex]

If I wasn't clear, I'm putting forth that “Ignore TLS certificate errors” does not ignore TLS certificate errors, only self-signed certificate errors.

[roman-r-m]

It should trust all certificates. Does yours have SubjectAlternativeName matching the host name?

EDIT Actually, this shouldn't be an issue.

[roman-r-m]

That log is useless for such errors. Can you connect using adb and search for exceptions during synchronization?

[OdinVex]

It should trust all certificates. Does yours have SubjectAlternativeName matching the host name?

EDIT Actually, this shouldn't be an issue. Wildcard, and other software (Firefox for Android) will recognize it as trusted when told to use the Android CS store. That log is useless for such errors. Can you connect using adb and search for exceptions during synchronization? I know, I've no idea why Joplin even has such logs, given the reason for the error is lost. I'll muck around to figure it out.

Edit: The logcat is just as useless. 12-17 14:05:41.533 3993 5035 I InputDispatcher: Delivering touch to (21476): action: 0x0, toolType: 1 12-17 14:05:41.534 21476 21476 D ViewRootImpl@1c5e35[MainActivity]: ViewPostImeInputStage processPointer 0 12-17 14:05:41.663 3993 5035 I InputDispatcher: Delivering touch to (21476): action: 0x1, toolType: 1 12-17 14:05:41.666 21476 21476 D ViewRootImpl@1c5e35[MainActivity]: ViewPostImeInputStage processPointer 1 12-17 14:05:41.684 21476 21499 D JOPLIN : Set ignore TLS errors: true 12-17 14:05:41.795 21476 21499 D JOPLIN : Set ignore TLS errors: true (I started the app, went into Configuration, connected with adb, clicked Check Synchronization Configuration. Unfortunately it has nothing useful as to the error.)

[roman-r-m]

It should trust all certificates. Does yours have SubjectAlternativeName matching the host name?

EDIT Actually, this shouldn't be an issue. Wildcard, and other software (Firefox for Android) will recognize it as trusted when told to use the Android CS store. That log is useless for such errors. Can you connect using adb and search for exceptions during synchronization? I know, I've no idea why Joplin even has such logs, given the reason for the error is lost. I'll muck around to figure it out.

This log is useful when an error originates from the js side. In this case however this is coming from the native code, I think the library Joplin uses only reports a generic network request failed message

[roman-r-m]

That seems unrelated, something to do with file system access.

[OdinVex]

That seems unrelated, something to do with file system access.

By the logs, it only happens shortly after checking synchronization, but alright. Nothing else stands out at all.

[OdinVex]

By the way, the Linux version of Joplin won't work without “Ignore TLS certificate errors”, despite the CA being trusted by my OS (added to Linux certificate store). Need an option to trust OS certificate store. Oddly enough, if I repeatedly tap to check the configuration, sometimes it'll print out JOPLIN : Set ignore TLS errors: **false** instead of true (even if the checkbox is ticked). Using plaintext (http) succeeds.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved. I'm considering using a VPN to short-node my connection and then over http...sigh

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[OdinVex]

Check out DAVx5, open-source, they include a switch to trust/distrust Android certificate store.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[andersonfreitas]

I have a custom CA and trusted on my Android. Enabling the “Ignore TLS certificate errors” works and synchronizes with a Joplin Server (with the flag unchecked it doesn't), however, it seems that the way images are downloaded uses a different connection scheme that ignores the “Ignore TLS certificate errors”, so no images are downloaded from notes (exception java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.).

[OdinVex]

@andersonfreitas, That usually means the server hosting the images isn't sending the root/intermediate certificates with the certificate during connection. When a TLS connection is made, the entire 'chain' of certs (or a subset) is sent. Yours is probably just the end entity, bad practice. What version of Joplin are you using? What version of Android? Is it a cert added to the Android System Store?

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved. Starting to wonder how many issues Joplin really has if they're constantly automatically closed as suggested.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[gbakeman]

Adding on to hopefully see some movement on this, and fend off the aggressive bot (lol.) More detailed error messages would be nice, too.

[OdinVex]

Adding on to hopefully see some movement on this, and fend off the aggressive bot (lol.) More detailed error messages would be nice, too.

No need for more detailed error messages, it's an issue regarding Joplin simply not using System-trusted certs or even the ability to trust thumbprints.

[gbakeman]

No need for more detailed error messages, it's an issue regarding Joplin simply not using System-trusted certs or even the ability to trust thumbprints.

Right, and I don't mean to go too far offtopic, but I've just spent far too much time troubleshooting this problem before I even thought it could be a TLS issue. As I think the beginning of your report implies,

Yet another “Network Request Failed” post.

This message is very common, and also quite unhelpful. But as someone else later said, it's a native library that generates the error so it sounds like the Joplin team has their hands tied on that subject.

Again, sorry for going offtopic - hope this issue specifically is fixed.

[OdinVex]

This message is very common, and also quite unhelpful. But as someone else later said, it's a native library that generates the error so it sounds like the Joplin team has their hands tied on that subject.

Turning off TLS/SSL, it's fine. Using a LetsEncrypt cert or one from a common CA, it's fine. Use my own CA, not fine, because it doesn't trust the cert. I had the problem with the desktop version until I forcibly told it what folder to use for certs punching through Flatkrap's ****ty sandboxing. It's a cert store issue. Software should trust the system cert store. Joplin's hands may be tied, I'm just keeping this alive until fixed. A ton of these RADs for web-based “apps” all use the same moronic backends that don't follow standards for certs and only trust their own included certs. An example would be Firefox. This crappy behavior is Firefox's default, along with their completely-misguided walling on connection trust workarounds. You have to enable a config option to trust the system store. Baffling behavior. I can comprehend providing users an option to NOT trust the system store, but it should be trusted by default. Worst case? At least optional use of the system store, configurable by the user.

[bryab]

I just would like to add that I have the same problem. It's funny because I only enabled SSL on my local web server to satisfy the requirements of the Jopin iOS app, which now requires that all connections be made over https. I got iOS working with a trusted CA cert, but now Android doesn't work because the Joplin Android app doesn't respect the system's trusted certs.

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[OdinVex]

It is unresolved.

[personalizedrefrigerator]

I'm adding this to my to-do list!

(No promises that I'll be able to fix this any time soon, though!)

[OdinVex]

I'm adding this to my to-do list!

(No promises that I'll be able to fix this any time soon, though!)

I think a fundamental library change is required. Something about an upstream library needing it.

[personalizedrefrigerator]

That's probably the case. However, it's also possible it's an issue with network_security_config.xml (documentation).

[OdinVex]

Maybe...but I don't see it trusting the system store, though, unless this Joplin doesn't have “system”. The documented section on “Configure a custom CA” sounds promising, save for the fact that it needs it as a resource? I don't do Android development, is this limited to deployment resources or can that reference a user-writable folder or, better, just trust the system store?