LE/DST expired root: workaround #2

[Tomas Mraz]

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.]