Hi,
I created a Lets Encrypt certificate with the alternative chain a few days ago.
Then my application, the Seafile Client / Windows 10 reported an invalid certificate.
After I created a new certificate with the new default chain, the client reported no problems with the certificate.
With the new default chain, however, the DST Root CA is still the anchor, which expires at the end of September 2021.
Do I therefore have to expect problems from October onwards?
It wouldn't surprise me. 
I have already contacted Seafile and received the answer that the Seafile client use the system certificate store.
But if this is the case, then this should also work with the alternative chain, or am I wrong here?
But since it throws an error with the alternative chain, I will probably also get an error with the new default chain from October, or am I wrong here?
Well my website is https://hp-67.com/
And here are 2 views of the certificate chain:
If the web browser doesn't think ISRG Root X1 is the end of the chain but believes that DST Root CA X3 is the end of the chain
then you will have an issue.
The web browser (Firefox) is not the problem, this one did not throw an error with the alternative chain, it was just the Seafile client.
But as far as I know browsers like to use their own certificate store...
Yes the Roots of Trust (i.e. the CA's [Chain of Trust - Let's Encrypt](Chain of Trust)) for the Certificates are store in most modern web browsers.
Also search for DST Root CA X3; and find like these 2.
Yes, I have already seen these two threads, but they are rather general.
Windows 10 should have the ISRG Root X1 in the certificate store according to this list.
So either Windows 10 does not support the ISRG Root X1, or the Seafile client does not use the system certificate store.
hmm root lazyload problem? can you open a isrg root x1 site with ms edge and try seafile again?
From my point of view it depends on what the browser takes as the Root Certificate,
as ISRG’s “ISRG Root X1” is both (at the moment) an Intermediate and Root Certificate.
If the browser takes it as the Root Certificate, then you should be good.
If the browser takes it as an Intermediate Certificate, then you will have an issue.
Again, the browser is not my problem, my problem is the the seafile client, which is a desktop application, for e.g. Windows10.
Or am I missing something?
A customer (also Windows 10) had the same problem with the Seafile client, is that likely that the lazyload problem occurs with two different computers at the same time?
I will test this anyway, but first I have to create a certificate with the alternative chain again.
I'll do that tomorrow and let you know.
Thanks for the hint.
Most browsers, on Windows, ask Windows for the certificate management; the notable exception is Mozilla Firefox.
So the question is how does the
[quote="Viktor21, post:12, topic:160321"]
Seafile client
[/quote] do its certificate management?
what I call by lazyload problem:
EDIT: Summary of the issue after discussion below and more fiddling around.
- Some W10 versions don't ship with ISRG root baked in
- If a browser (IE, Edge or Chrome) encounters an ISRG root signed certificate, it DOES lazy load the ISRG root and it DOES appear in the root store.
That being said, non-browser OS subsystems (like rasdial, maybe others) do NOT trigger this flow and the chain cannot be verified until the ISRG root is lazy loaded through a browser.
The real "issue" here is that Rasdial is referencing the on-disk root store without using the OS's built in validation routines, and therefore isn't able to take advantage of the OS's lazy-loading.
maybe seafile have same problem?
With Windows 10 there is the issue of Windows updates, that I believe also updates Windows the certificate management root certificates.
As I wrote earlier, I have already asked this question to Seafile.
There I received the answer that the Windows Store is used.
I should be able to see this tomorrow when I have the certificate of the alternative chain again and then my application in the browser (Chrome / Edge) does not throw an error, but in the client it does.
In that case it is probably pretty sure that the client does not use the Windows store.
Yes I found this thread too after you brought up the lazy load issue.
As I said I'll test it and then we'll see what happens
it surly will. I found relevant source code from seafile client repo.
https://github.com/haiwen/seafile/blob/master/daemon/http-tx-mgr.c, from line 430
this loads ca list from local certificate store, load it into curl. it won't able to lazyload new root from online store in runtime.
Nice work @orangepizza ; thanks! 
RE: Lazy Loading
Have a look at : ISRG Root lazy loading problem + missing from (random) updated Windows 10 versions - #18 by rg305