On Wed, 6 Oct 2021, Thiago Macieira wrote: > If OpenSSL has any path to a still-valid root certificate, then it can ignore > the others. That's one way of dealing with expirations: you add a new link in > the chain that will continue to be valid when the other path(s) aren't. You > can also prune the tree that isn't necessary any more -- I looked into what > Let's Encrypt has been giving me for months and it hasn't included the > expiring certificate in the certchain.pem collection.
You don’t add root certificates to the chain the server delivers to the client though, which creates a problem if the depth changes, like with LE: LE before: server cert ← R3 intermediate ← X1 intermediate ← X3 root └─────────────────────────────────────────────┘ Only those within the bracket are shipped by the server. Now X1 is also a root. The client has no way to know that *EXCEPT* if it has the X1 certificate in its *root* store ahead of time (with a self-signature), because otherwise, the X1 certificate shipped by the server has an Issuer that is not X1, so it’s obviously not a root certificate (in the role the certificate has in that chain). Older OpenSSL versions now also fail with this unless patched to add the workaround from later OpenSSL versions, namely, that if a certificate of the chain is also part of the local root store (now a root/intermediate trusted store), it’s accepted. This means LE’s transition *cannot* work with lazy loading, specifically because the client *cannot* know that there even *is* anything to load, because the depth changed. The situation would have been different if X1 would now be signed by another root, but that would mean every user would have needed to get the certificate chain updated at the same time. That’s the less likely to succeed variant. New LE certificates still ship the X1-signed-by-X3 in their chain and fullchain. I’ve reported this to LE, but apparently they continue doing so, against the spec (which says root certificates shall not be shipped as part of the chain) because old Android devices apparently don’t check root certificates’ expiry date, so the X1-signed-by-X3 continues to work for them. On my own servers I’ve adapted my dehydrated hook to remove the faulty intermediate, but of course this depends on server admins to DTRT, plus it’ll apparently cause more trouble for Android… tl;dr: don’t lazy-load the root certificate store, you may never know when you’re going to need which certificates. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption! **************************************************** _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
