Home / GitHub Page

Sync errors with both Dropbox and OneDrive (self signed certificate)

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.

1 Like

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…

Android client: Network connection error

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 :slight_smile:

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”?

1 Like

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! :smiley:

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.

1 Like

I agree. For me this looks like a a MITM attack.

1 Like

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..
---
DONE