On Thu, 2021-09-30 at 21:28 -0400, Felipe Gasper wrote: > Hello, > > > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ > > ^^ This document indicates that, by enabling trusted-first mode, I > should be able to work around the LE expiration problem. > > I’m either misunderstanding this or “holding it wrong”, though, > because I can’t see that setup making any difference. > > I’ve got a chain with: > 1) leaf cert (felipegasper.com) > 2) Let’s Encrypt R3 > 3) … and the cert called “ISRG Root X1” that is *not*, in fact, a > root cert > > Cert #3 in the above is issued by the now-expired “DST Root CA X3”, > so including it (understandably) “misleads” `openssl verify` into > looking into its root store for that cert’s issuer, which causes a > verification failure. > > I notice, though, that connection handshakes succeed despite the non- > self-signed “ISRG Root X1” being part of the sent chain. > > Is there a way I can make `openssl verify` behave the same way as > connection handshakes? So the 3 certs I have in my chain will pass > OpenSSL’s dedicated verification logic? You need to have a self-signed ISRG Root X1 as a trusted cert in the openssl verify. That self-signed ISRG Root X1 is contained in up-to- date OS certificate trust stores so that's the reason why connections succeed (with 1.0.2 in case the -trusted_first is used). The 1.1.x or 1.0.2 will ignore the non-self-signed ISRG Root X1 certificate and use the self-signed ISRG Root X1 to verify the Let's Encrypt R3 intermediate cert. However 1.0.2 without -trusted_first will always try to verify the path via the non-self-signed ISRG Root X1 which leads to the expired DST Root CA X3 cert in the trust store which then fails the verification. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
