"FetchError: certificate has expired" with valid certificate #3348

czenk · 2020-06-08T15:15:48Z

(Source: https://discourse.joplinapp.org/t/nextcloud-webdav-cert-error/9157 )

Four users so far have reported that resync is defunct for providers

-NextCloud
-WebDAV

since the beginning of June 2020 on

Linux (reported: Ubuntu 18.04.3 TLS)
Windows (reported: Windows 10)
MacOS (reported: MacOS 10.15.4 (Catalina))

(Android seems unaffected so far).

Temporary workaround: Enable "Ignore TLS certificate errors" in advanced synchronisation settings.

I can reproduce the issue myself on Linux and Windows 10 installation accross two devices (whilst iPad and Android continue to work without issues) against https://ssl-account.com.

Reproduced with the following Portable and installed Windows versions of the Joplin Desktop Client:

Joplin 1.0.201 (prod, win32)

Client ID: 7713f66e74614769884e389475c1f51d
Sync Version: 1
Profile Version: 28

Revision: `e65af8c` (master)

Joplin 1.0.216 (prod, win32)

Client ID: 1d51edd102a34dceb00201b3db75f962
Sync Version: 1
Profile Version: 29

Revision: 4eb680d (master)

Joplin 1.0.218 (prod, win32)

Client ID: fd97fb0931f641edb69400861af7d7bd
Sync Version: 1
Profile Version: 30
Keychain Supported: No

Revision: `5be8c2c` (master)

Debug logs from these versions using

OS: Windows 10 Pro Build 18362.836

attached.

Screenshots with error message attached.
JoplinLogsWin10.txt

Steps to reproduce

Configure synchronisation for WebDAV
Ensure "Ignore TLS certificate erros" is NOT checked
Synchronise

Please do not hesitate to contact me for further information or PM/email me for a remote session via Discord as needed. I can also offer to setup another temporary account against my sync-target for the purpose of testing, should this help to identify/reproduce the issue.

Describe what you expected to happen

Sync is expected to work seemlesly against a sync-target exposing a valid certificate.

Logfile

JoplinLogsWin10.txt

The text was updated successfully, but these errors were encountered:

laurent22 · 2020-06-08T16:01:41Z

I'm not certain we can do something about it, at least I have no idea what could be done. We don't do anything special with certificates, we just use the built-in network capabilities of the OS and libraries.

Maybe it's due to some changes in Electron or Chrome so it could be worth checking their bug trackers for any clue.

roman-r-m · 2020-06-08T16:21:57Z

Hi @czenk could you set up an account for me? I'd like to give it a try.

czenk · 2020-06-08T17:35:33Z

Hi @roman-r-m,
Sure, I'll try to get this ready for you tomorrow. How can we get in touch on a "non-public" channel to exchange credentials?

On a separate note I just added a Wireshark trace to the bottom of the ticket - as you requested in the related thread.

TS.

roman-r-m · 2020-06-08T19:02:14Z

Sure, I'll try to get this ready for you tomorrow. How can we get in touch on a "non-public" channel to exchange credentials?

That won't be needed.

Here's what I see when connecting to your server (took the ip from your trace)

(this is Firefox on Windows 8)

Your certficate is expired. It's one of the itermediate certificates:

I'm guessing your Android has a newer version in the system store and that's why it is able to connect.

czenk · 2020-06-08T20:49:41Z

Hi @roman-r-m,

Thank you very much for looking into this. Apologies for not being into the intricacies of Certificate Management, but I am afraid I need your help to understand this:
The certificate should be for the domain ssl-account.com (which is the Cert proxy of my webspace provider in Germany). This is the certificate information I get when I access the web front-end of my OwnCloud instance, proxied via ssl-account.com:

How is the certificate you posted above related (thx. for masking the suspected domain btw. ;-) ?
Is there potentially some DNS-spoofing at hand? Or a local store that is lacking a refresh?

Thanks again - stay safe

roman-r-m · 2020-06-08T21:24:40Z

Is there potentially some DNS-spoofing at hand? Or a local store that is lacking a refresh?

I do not think there's anything to worry about here (well, other than the expired certificate).

Your server sends not only its own certificate but all other intermediate certificated leading up to the root certicficate. One of those certificates has expired -- it should have been handled by whatever process of refreshing certificates that you have, you might want to check why it was not refreshed.

thx. for masking the suspected domain btw

I actually just used the ip from your trace -- you might want to remove it now just in case.

On your screenshot if you switch to the details tab in Certificate Viewer you should see your intermediate certficates.

roman-r-m · 2020-06-08T21:26:37Z

Anyway, I think it's safe to say this issue can be closed now.

tessus · 2020-06-08T21:34:09Z

The end user can't do anything. The web space provider (or the backend service they are using) will have to update the intermediate cert.

roman-r-m · 2020-06-08T21:36:19Z

For some reason I assumed it was self-hosted

tessus · 2020-06-08T21:41:14Z

The OP mentioned that the SSL is proxied by the web hoster. But maybe I misunderstood.

czenk · 2020-06-08T22:50:53Z

Hi roman-r-m, hi tessus,
Thanks for the explanation. Yes, SSL is proxied by the web hoster - the site is not self-hosted. I will get in touch with my provider so (fortunately they have proven to be exceptionally professional and helpful over the past 16 years).

I guess the question remains what the other users reporting this issue can do - but from what I understand this does not seem to be an issue with the Joplin codebase for as long as you want to verify the whole certificate chain.

tessus · 2020-06-09T00:51:54Z

Correct, this has nothing to do with the Joplin code base. What I'm not really clear about is that people say they didn't get a warning when they connected via a web browser. So the web browser ignored the fact that the intermediary has expired? Hmmm, something is off.

Either way, usually the person or company that uses the certificate is responsible to make sure the chain is valid. e.g. you do not only specify the cert and key in the server configuration, but the entire chain. However, if the company that provides the cert fails to inform you that their intermediary cert has expired, it's mostly their fault. That's why I usually make sure that the chain is valid, no matter what.
So in your case, the proxied connection has to be fixed by the company that provides the proxied connection (since they are the ones who set up the cert).

Additionally to that, the client also keeps root CAs in their local cert store. Browser, OS, curl, .... Now it can also be the case that these certs have not been updated properly, although this usually doesn't happen very often - but it can happen.

So the other users can make sure that all cert chains are valid. Depending on where the chain is broken, either they have or somebody else has to fix it.

joergister · 2020-06-09T07:15:24Z

sounds like it is connected to the problem described here https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration since I can acces my hoster without an error but I can't connect to it from macOS (iOS works on the other hand).
there is more information von sectigo https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 and there is a patch in gnu tls that is to be shipped with the next release. https://gitlab.com/gnutls/gnutls/-/commit/cdf075e7f54cb77f046ef3e7c2147f159941faca

joergister · 2020-06-09T07:16:27Z

seems like we just have to wait for the next gnuTLS release to be shipped with Joplin.

roman-r-m · 2020-06-09T07:54:35Z

@joergister does it affect windows? czenk had the issue on windows

joergister · 2020-06-09T08:44:12Z

as long as the library that is affected is also in use on windows (or in Joplin on windows, or in electron for windows), it does.

joergister · 2020-06-09T09:09:00Z

@roman-r-m @czenk you could test test your server (to which Joplin tries to connect) against https://whatsmychaincert.com to see if it has a trusted chain containing an expired certificate. This chain will work with modern web browsers (they will use a chain to a different trusted root) but may fail with older clients or Joplin.

edit : test your -> test your server (to which Joplin tries to connect)

tessus · 2020-06-09T12:59:19Z

seems like we just have to wait for the next gnuTLS release to be shipped with Joplin.

Nope. Joplin does not bundle SSL/TLS. Joplin uses the OS'a SSL/TLS implementation.

czenk · 2020-06-09T15:27:10Z

Thank you all so much for sharing your expertise and educating me on the matter.

To recap what I understood:

The root cause has been identified as an expired intermediary certificate which causes the validation of the certificate-chain to fail - independent of the validity of the service providers domain certificate.
Joplin utilises a 3rd party (gnuTLS?) library for Certifate Management. (Oversimplified:) Joplin calls a method provided by that library, expecting a TRUE/FALSE validation response for a given certificate (and its chain).
A fallback mechanism is available in case a certificate in the chain is expired. However, the 3rd party library Joplin depends on has not implemented the fallback (yet).

Did I get this correct?

Agreed, this turns out not to be a bug ( but rather a "Change Request" on hold, pending dependencies?). Anything I should be doing here?

How can I contribute back? Should I try to write up something for a troubleshooting-/support-/faq-section or finalise the related forum thread in user language accordingly? Shall I update the top of this issue with the above (so there's no need to wade through the whole history)?
Also do not hesitate to ping me for further related tests as needed.

... sounds like it is connected to the problem described here https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration ...

Eye opener. Thanks a mil for the link.

you could test your server (to which Joplin tries to connect) against https://whatsmychaincert.com ...

I gave that a shot and got the following (fitting) response:

... has a trusted chain containing an expired certificate. This chain will work with modern web browsers (they will use a chain to a different trusted root) but may fail with older clients, notably OpenSSL 1.0.x. Download a chain without the expired certificate

Cheers - stay safe

tessus · 2020-06-09T16:28:18Z

If so, I believe the classification of this issue needs to be changed from "bug" ( to "Change Request" on hold, pending dependencies?). Anything I should be doing here?

Nope, but you can talk to the OS providers (Microsoft or Apple) to update their shit.
And the one who's responsible for the proxied connection has to update the chain.

So nothing to do for you. This can't be fixed by you or us.

tessus · 2020-06-11T22:13:16Z

@czenk you can summarize the comments here (or the parts which are most important) and post in the discourse topic you mentioned in the first post.

Then you can close this issue, since it's not a bug.

TheManchineel · 2021-09-30T21:49:01Z

This has now resurfaced. I'm on the latest version (2.4.9, prod, win32), although it doesn't happen on macOS for me, only Windows. I have this issue with my Joplin Server, although the same error appears if I enter any of my domains sharing the same *.example.com wildcard certificate emitted by Let's Encrypt. I could sync my notes just fine up until yesterday, I made no changes to the server side, I checked my certificate chain with the tools mentioned above (all ok), and as I mentioned this works fine on every platform exception made for Windows. Even all Windows apps, including browsers (Edge, Chrome, Firefox) and the Windows PowerShell have no trouble connecting to my domain.

Here's a native PowerShell curl invocation on my Joplin Server URL:

StatusCode        : 200
StatusDescription : OK
Content           : <!doctype html>
                    <html>
                    <head>
                        <title>Joplin Server - Login</title>
                        <meta charset="utf-8">
                        <link rel="stylesheet" href="https://joplin.example.com/css/bulma.min.css"
                    crossorigin="anonymous">
                    ...
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Vary: Origin
                    Content-Length: 2779                                                                                                    Content-Type: text/html; charset=utf-8                                                                                  Date: Thu, 30 Sep 2021 21:43:02 GMT                                                                                     Server: nginx/1.18.0 (Ubuntu)                                                                                                                                                                                                                   <!doctype htm...
Forms             : {}
Headers           : {[Connection, keep-alive], [Vary, Origin], [Content-Length, 2779], [Content-Type, text/html;
                    charset=utf-8]...}
Images            : {@{innerHTML=; innerText=; outerHTML=<IMG class=logo
                    src="https://joplin.example.com/images/Logo.png">; outerText=; tagName=IMG; class=logo;
                    src=https://joplin.example.com/images/Logo.png}}
InputFields       : {@{innerHTML=; innerText=; outerHTML=<INPUT class=input name=email>; outerText=; tagName=INPUT;
                    class=input; name=email}, @{innerHTML=; innerText=; outerHTML=<INPUT class=input type=password
                    value="" name=password>; outerText=; tagName=INPUT; class=input; type=password; value=;
                    name=password}}
Links             : {@{innerHTML=<IMG class=logo src="https://joplin.example.com/images/Logo.png"> ; innerText=
                    ; outerHTML=<A class=navbar-item href="https://joplin.example.com/home"><IMG class=logo
                    src="https://joplin.example.com/images/Logo.png"> </A>; outerText= ; tagName=A;
                    class=navbar-item; href=https://joplin.example.com/home}}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 2779

I'm on the latest Windows 11 build.

tessus · 2021-09-30T21:57:54Z

No, it hasn't. See the forum for the reason and what is going on.

dniku · 2021-10-01T09:08:39Z

@tessus mind posting the link to the post with the solution? I second the report from @TheManchineel: up until yesterday, Joplin sync had been working fine with my Nextcloud server, but yesterday it broke with the exact same error.

laurent22 · 2021-10-01T09:32:35Z

That would be the thread: https://discourse.joplinapp.org/t/certificate-has-expired-error-with-joplin-cloud-and-workaround/20638 Initially about Joplin Cloud but also applies to any server that uses Let's Encrypt.

lucker999 · 2021-10-01T09:38:56Z

+1
The very same issue surfaced today on version 2.3.5. Update to the latest 2.4.9 doesn't solve it. Affects both machines with Windows, but Android works perfectly.
UPD: Sorry, posted before the response from laurent22 appeared.

tessus · 2021-10-01T09:44:32Z

The message is the same, but the cause is a different one.

czenk added the bug It's a bug label Jun 8, 2020

laurent22 removed the bug It's a bug label Jun 9, 2020

laurent22 closed this as completed Jun 19, 2020

jtagcat mentioned this issue Sep 30, 2021

DST root cerficate expired, effects syncs. flathub/net.cozic.joplin_desktop#22

Closed

Repository owner locked as off-topic and limited conversation to collaborators Oct 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"FetchError: certificate has expired" with valid certificate #3348

"FetchError: certificate has expired" with valid certificate #3348

czenk commented Jun 8, 2020 •

edited

Loading

laurent22 commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

czenk commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

czenk commented Jun 8, 2020

roman-r-m commented Jun 8, 2020 •

edited

Loading

roman-r-m commented Jun 8, 2020

tessus commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

tessus commented Jun 8, 2020

czenk commented Jun 8, 2020

tessus commented Jun 9, 2020

joergister commented Jun 9, 2020

joergister commented Jun 9, 2020

roman-r-m commented Jun 9, 2020

joergister commented Jun 9, 2020

joergister commented Jun 9, 2020 •

edited

Loading

tessus commented Jun 9, 2020

czenk commented Jun 9, 2020 •

edited

Loading

tessus commented Jun 9, 2020 •

edited

Loading

tessus commented Jun 11, 2020

TheManchineel commented Sep 30, 2021 •

edited

Loading

tessus commented Sep 30, 2021

dniku commented Oct 1, 2021

laurent22 commented Oct 1, 2021

lucker999 commented Oct 1, 2021 •

edited

Loading

tessus commented Oct 1, 2021

"FetchError: certificate has expired" with valid certificate #3348

"FetchError: certificate has expired" with valid certificate #3348

Comments

czenk commented Jun 8, 2020 • edited Loading

Revision: e65af8c (master)

Revision: 5be8c2c (master)

Steps to reproduce

Describe what you expected to happen

Logfile

laurent22 commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

czenk commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

czenk commented Jun 8, 2020

roman-r-m commented Jun 8, 2020 • edited Loading

roman-r-m commented Jun 8, 2020

tessus commented Jun 8, 2020

roman-r-m commented Jun 8, 2020

tessus commented Jun 8, 2020

czenk commented Jun 8, 2020

tessus commented Jun 9, 2020

joergister commented Jun 9, 2020

joergister commented Jun 9, 2020

roman-r-m commented Jun 9, 2020

joergister commented Jun 9, 2020

joergister commented Jun 9, 2020 • edited Loading

tessus commented Jun 9, 2020

czenk commented Jun 9, 2020 • edited Loading

tessus commented Jun 9, 2020 • edited Loading

tessus commented Jun 11, 2020

TheManchineel commented Sep 30, 2021 • edited Loading

tessus commented Sep 30, 2021

dniku commented Oct 1, 2021

laurent22 commented Oct 1, 2021

lucker999 commented Oct 1, 2021 • edited Loading

tessus commented Oct 1, 2021

czenk commented Jun 8, 2020 •

edited

Loading

Revision: `e65af8c` (master)

Revision: `5be8c2c` (master)

roman-r-m commented Jun 8, 2020 •

edited

Loading

joergister commented Jun 9, 2020 •

edited

Loading

czenk commented Jun 9, 2020 •

edited

Loading

tessus commented Jun 9, 2020 •

edited

Loading

TheManchineel commented Sep 30, 2021 •

edited

Loading

lucker999 commented Oct 1, 2021 •

edited

Loading