The "Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2" blog 
article [1] doesn't cover OpenSSL versions prior to 1.0.2, presumably because 
they've been unsupported for a long time.  However, no doubt there are still 
some users and applications that are stuck using even older versions of 
OpenSSL.  Here are some solutions...

Firstly, it's worth noting that Workaround 1 (see [1]) also works with OpenSSL 
1.0.1n and above, which seems to be because the 1.0.2 "alternative chains" 
behaviour was backported (see [2]).

Secondly, I've come up with a variant of Workaround 1 (see "Workaround 0" 
below) that also works for even older OpenSSL releases.  I thought I'd share it 
here in case it helps anyone out...

Workaround 0 (on clients with OpenSSL >=0.9.8m)

Modify the "notAfter" date in the expired root certificate (DST Root CA X3) 
from "Sep 30 14:01:15 2021 GMT" to "Sep 30 18:14:03 2024 GMT" (which is when 
the new DST->ISRG cross-certificate is due to expire - see [3] and [4]); then, 
in the OpenSSL-based client application's trust store, replace the expired root 
certificate with the modified version.  Here's one way to create the modified 

wget -O DSTRootCAX3_Extended.crt "";
sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" DSTRootCAX3_Extended.crt

You should find that "openssl s_client" with "-CAfile DSTRootCAX3_Extended.crt" 
will return "Verify return code: 0 (ok)" when connecting to any server that 
serves Let's Encrypt's preferred certificate chain (i.e., the chain that 
includes [4]).  For example:

openssl s_client -connect -CAfile 

Why does this work?
Modifying the expired root certificate obviously invalidates its self-signed 
signature.  However, OpenSSL 0.9.8m and above don't check self-signed 
signatures by default (due to [5]), which is one factor in why this workaround 
works (whereas 0.9.8l and below do check self-signed signatures).  The other 
factor is that OpenSSL treats the modified certificate as a root certificate, 
because the Issuer and Subject Names are identical; since it's not treated as 
an intermediate certificate, older versions of OpenSSL are able to treat it as 
a trust anchor even though they lack the "partial chains" functionality that 
was added in 1.0.2 (see [6]).

It is not necessary to add the new ISRG Root X1 self-signed certificate to the 
client's trust store for Workaround 0 to work.  Note however that Workaround 0 
won't work beyond Sep 30 18:14:03 2024 GMT.







Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

Reply via email to