I believe -CAfile overrides the trusted certificate store. This means it won’t look at the default CA store. Try validating against fullchain.pem without forcing a specific CA file. If that doesn’t work, point the CAfile parameter to the system’s CA store.
You are having those issues because the Intermediate CA which signed your cert is cross-signed by IdenTrust (DST Root CA X3) and not by ISRG Root X1. When ISRG Root X1 could be included in the vast majority of certificate stores (S.O., browsers, etc.) Let's Encrypt will sign the certificates with the Intermediate CA which is signed by ISRG Root X1 instead of DST Root CA X3.
Our intermediate is signed by ISRG Root X1. However, since we are a very new
certificate authority, ISRG Root X1 is not yet trusted in most browsers. In
order to be broadly trusted right away, our intermediate is also cross-signed by
another certificate authority, IdenTrust, whose root is already trusted in all
major browsers. Specifically, IdenTrust has cross-signed our intermediate using their
DST Root CA X3
The certs don't have two signatures at the same time (in the same cert). You have a cert signed by an Intermediate CA Let’s Encrypt Authority X1 (signed by IdenTrust) or you have a cert signed by an Intermediate CA Let’s Encrypt Authority X1 (signed by ISRG).
okay, that’s an intresting fact so essentially the ISRG root does pretty much nothing as long as the cross sig is in place because that’s what is used, but wont ppl have to get new certs when the cross runs out, I mean it is a different intermediate.
well I doubt that (at least for now), the implementation still is very issued, like the official client runs only on linux, the server integration for apache only on debian, and the client requires root regardless of mode.
not to mention that it probably has enough dependencies and le-auto takes minutes to start before and after entering root-pw (at least on my raspi)
that gives a lot of doubt to server owners, especially because this thing updates its envoronment by itself which might cause unseen issues.
but the cross sign still has some years, unless browsers decide to distrust them (Mozilla got a bug for that, which is marked as invalid, for now, but if they dont give their full audit by like 20:22 UTC they might get in serious trouble) so unless something really bad happens they should have enough time to work on that.
The certificate chain is automatically provided by an "up" link in the certificate response. I guess LE will just send their own intermediate later, so nobody will have to upgrade anything. Automation solves all these issues even for intermediates.
Yes, I suppose both Intermediate CAs coexist in time to make the transition. Regarding the Mozilla issue, I saw your post and I'm waiting for any Let's Encrypt member staff could shed some light on this audit issue
There shouldn’t be any transition problems as both certificates(ISRG-signed & cross-signed) have the same public key to validate the signatures on the end-entity certificates, so all server owners would need to do would be to deliver a different intermediate certificate.
so for the sig only the key is important?
well quite nice. resolves issues if you need a different intermedia tbecause of a rename or whatever.
well I dont thnk I want a website being completely responsible for my keys and certs and I dont think that your average webserver has write access to the cert location, and not even read access if privilege dropping is in there.
