With a new install of Joplin on MacOS (Mojave 10.14.4), I continually get sync errors and sync never completes. The same issue exists with both Dropbox and OneDrive with the same error message:
failed, reason: self signed certificate in certificate chain
Any suggestions?
Can you provide more context for the log (the lines before and after the one youāve posted)?
Sure, hereās what Iām seeing:
DropBox:
created remote items: 1.
Completed: 01/05/2019 09:30
Last error: FetchError: request to https://content.dropboxapi.com/2/files/upload failed, reason: self signed certificate in certificate chain
OneDrive - this is after I have successfully signed in to my Office365 account via Joplin:
Could not login to OneDrive. Please try again.
request to https://login.microsoftonline.com/common/oauth2/v2.0/token failed, reason: self signed certificate in certificate chain
There is another very long URL after the OneDrive error above, but since Iām new to this forum itāll only let me add 2 links to a post.
You should use codeblocks to post log or any data that is code. In that case links are not counted as links either. Iāll change your post and you can see what I mean.
When I come to think of it. How can there be a self-signed cert in the chain when you connect to a valid TLS cert?
Are you using some sort of a proxy, or trying to use mitm-proxy or Charles Proxy? Something doesnāt smell right here.
Seems that this is yet another case where self-signed certificates are causing issues. Fortunately, the desktop app allows this to be resolved by providing a choice to avoid TLS errors as well as a choice of where the app should reference the certs. Unfortunately, the same canāt be said of the Android appā¦
If you connect to Google or Dropbox where is there a self-signed certificate? Also, did you see that the OP was talking about the desktop version?
Good to know. Thank you 
No proxy. I'll try from my home network later tonight to see if I get a different result.
I tried again on my home network, and confirmed that Iām getting the same errors with both Dropbox and OneDrive.
In the config screen, in your Nextcloud or WebDAV settings, do you have something set for āCustom TLS certificatesā?
No, the Nextcloud and WebDAV settings were blank.
But, in WebDAV, I enabled "Ignore TLS certificate errors", and then changed the target back to Dropbox. And that worked - it's syncing properly now.
I'd suggest moving that "Ignore TLS..." option outside of the targets, since it's currently only visible under WebDAV and Nextcloud.
Anyway, that was a huge help - thank you! 
This is quite strange though. If itās not a bug in Joplin then thereās something not right with your internet connection. If someone was MITM your connection, it would give this kind of error, but even if itās not malicious thereās something weird going on, so you probably should try to find the root of the problem.
I agree. For me this looks like a a MITM attack.
This is all happening on a work-issued laptop that has some anti-virus network software running. So maybe that is causing this to act like a MITM issue, since it happens on both my home and office networks.
Iāll try installing Joplin on another machine and see if it behaves the same way on both networks.
Iād like to report that the same thing is happening to me. I tried to synchronize the Joplin installed on my USB stick with Dropbox and the same error message appeared.
The error also repeats when I try to check for Joplin version updates.
Joplin is only synchronizing with Dropbox if I enable the āIgnore TLS certificate errorsā dialog in WebDAV. However, Joplin still gives the same error when I try to check for updatesā¦
I use Joplin on my USB stick when Iām at workā¦
This is common on business-issued machines. Lots of places use a proxy (like a Barracuda or various cisco appliances) to intercept https traffic so they have visibility into employee usage and/or for data exfil protection, etcā¦ For brevity in the reply, see, e.g., https://www.grc.com/fingerprints.htm . If you examine your browser or OS certificate store, you will most likely find a custom root cert so your browsers donāt throw an error on every https connection.
You can also test this yourself with openssl. You can see the whole certificate chain with this, think of it like tracert for certs.
$ echo -n | openssl s_client -connect content.dropboxapi.com:443
CONNECTED(00000004)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Dropbox, Inc", OU = Dropbox Ops, CN = content.dropboxapi.com
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = San Francisco, O = "Dropbox, Inc", OU = Dropbox Ops, CN = content.dropboxapi.com
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
..snipped..
-----END CERTIFICATE-----
subject=C = US, ST = California, L = San Francisco, O = "Dropbox, Inc", OU = Dropbox Ops, CN = content.dropboxapi.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3943 bytes and written 419 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
..snipped..
---
DONE
or
$ echo -n | openssl s_client -connect joplinapp.org:443
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = joplinapp.org
verify return:1
---
Certificate chain
0 s:CN = joplinapp.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
..snipped..
-----END CERTIFICATE-----
subject=CN = joplinapp.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3206 bytes and written 418 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
..snipped..
---
DONEI submit that there is a bug somewhere. I have seen multiple posts on this where the solution in the end is to "ignore TLS certificate errors". And yes this works for me as well, but this is not ideal when using my device off of the corporate network. A bug was submitted through github, but they were directed to post here.
While some users might be having issues due to Mitm or self signed certs out of ignorance. I am definitely MiTM my connection due to enterprise requirements and I am familiar with this process.
To recreate:
I open my webdav url in a browser and export both crt, cer certificates in the chain to a location on my computer, Then convert them to public pem files, because that is what it appears to handle. (yes i know that they are technically the same file contents, but I used openssl just to be certain)
In the settings I then pointed "Custom TLS certificates" to the location on my computer c:\certs that houses both certificates. I have also tried using a comma separated list to the pem files, but to no avail.
It appears that it is just not applying the "Custom TLS certificates" setting.
I have same problem than you with Joplin.
In my company, we have ssl inspection, itās a āMen in the middleā which been installed by ācheckpoint company.ā To avoid this problem, we have to add our āCA certificateā in our Linux (openssl) or our Windows (automatically by GPO).
For example, for git, we have to export certificate(certmgr.msc) and import them in local repository of openssl.
This link will be more clear to explain you how it works for it.
https://mattferderer.com/fix-git-self-signed-certificate-in-certificate-chain-on-windows
For my Windows(certmgr.msc), the CA root certificate is already present in my local session(Trusted root Certification Authorities -> Certificates). But not considered by Joplin.
But for Joplin, I donāt know how to add āTrusted Root certificateā under Linux and Windows.
Thanks for your help.
