Seafile client DST Root CA expiry

So i generate a new cert for my domain, only ISRG Root X1 is now the root, so far so good.
However, now I no longer get the certificates error with the Seafile client.
I also tested a snapshot from 5 months ago and it suddenly works now too

1 Like

Okay I tried it again with another Windows 10 machine and there I could reproduce it.

The Seafile client threw an error on a Seafile server with the ISRG Root X1 Root CA.
After I opened the web user interface of this Seafile server with Chrome, I had to restart the Seafile client afterwards, but then it worked without problems.

Possibly a Lazy Loading issue.
Have a look at : ISRG Root lazy loading problem + missing from (random) updated Windows 10 versions - #18 by rg305

Stepping back from what everyone else said here:

  1. One of the following two things could have caused your issue:

    • The CLIENT has an error and does not recognize the new chain
    • The Operating System does not have the new root in it's trust store.

    I do not know anything about your client, however it is very possible that only the client has an issue.

  2. That The Leaf/EndEntity certificate created for the default and alternate chains are interchangeable. You do not need to create a new certificate using the other chain, you can just use the same certificate and swap the chains.

That being said, the easiest way to test where the problem is in your situation may be to manually swap the chains for a certificate, and see how different browsers interact with the server.

From what others have posted, it looks like the issue may be with the Client not using the updated trust store. Swapping the chains on the server may be an easier way to initially test that, rather than trying to keep using potentially incompatible/broken software.

  • The Operating System does not have the new root in it's trust store.

I think this is the lazy load problem that @orangepizza already mentioned first.

As just described, the following case exists

  1. The Seafile client throws an error.
  2. After opening the Web UI of the Seafile server with Chrome, the current Lets Encrypt Root CA is stored in the Trust Store.
  3. After restarting the Seafile client, it no longer reports an error.

The question that is still open is in which cases this error will occur as of October.
I assume that it will not affect all users who use Chrome / Edge, since they will most likely visit a page that has a Lets Encrypt certificate and will then include the Lets Encrypt Root CA in the Trust Store.

How does it look here with Firefox, is there also in addition to Firefox its own Trust Store, the Root CA also stored in the System Store?

And what about current macOS versions and Linux distributions.
Does it look better here with the Lets Encrypt Root CA in the System Trust Store, or do we have to expect similar problems?


Reference the compatibility chart you posted earlier and focus on the "Platforms that trust ISRG Root X" section: Certificate Compatibility - Let's Encrypt

Firefox has it's own trust store for several years. Firefox 50 was released on 2016-06-06.

Chrome has announced it will have a private trust store in the future, but I don't think there is a date.

For macos/ios/linux/etc, it depends on the version the visitor is using. If the OS/device was released within the past 5 years, it should be trusted.


As an aside, I recently (yesterday) started up a brand new Windows Server 2022 instance on Azure. It did not know about ISRG Root X1 (and still doesn't after running windows update). Fun times!

[Note that visiting a site that uses Leaf > R3 > ISRG Root X1 > DST Root CA X3 in Chrome etc is not enough for lazy loading to fix the issue, the site has to be serving the shorter Leaf > R3 > ISRG Root X1 chain]


:frowning_face:That is just disappointing, one would think Microsoft could do better than that! :disappointed:

1 Like

feels like MS lazyload thing worth a dedicate thread, maybe even pinning for a while if we find one liner solution I guess.


@webprofusion, do you mean to say that it requires both things?
[Lazy Loading & use shorter chain]


Just one thing will fit it?
[use the shorter chain]

I could imagine that the long chain will be sufficient from October because the DST will have expired and the chain will be shortened to the ISRG Root X1.
Or is it naive to assume that there is so much logic inside?

Yes I think a pinned thread would be very important and helpful pointing out this problem incl. a solution

1 Like

a one liner command to run in windows clinet to fetch the ISRG root from MS:
powershell invoke-webrequest -usebasicparsing

powershell invoke-webrequest uses MS's verification stack so it can fetch new root certificate from MS
-usebasicparser is because otherwise you need initialized internet explorer to run, which I can't assume

it will spit out result of webrequest but you can discard it.


Yeah I'm confusing the issue, the difference between acting as a client or acting as a server are two entirely different problems. Just ignore me :slight_smile:


Maybe not.
I'm sure we'll get our fill of knowledge soon enough :wink:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.