How to fix SSL issue from 30-September-2021 [duplicate]

The "update" is just the actual non-cross-signed ISRG Root X1 certification authority that Let's Encrypt will be using from now on. (Download the "Self-signed DER" version.)

What needs to be fixed

There's nothing to update from the software side, as the X.509 and TLS stack built in to Windows is already quite good at dealing with multiple validation chains. (It has to be able to cope with the US DoD Federal PKI, which uses cross-signing extensively. Just look at this graph! The AddTrust and ISRG situations are relatively tame in comparison.)

So in the beginning, while websites are still sending you the DST → ISRG X1 → LE chain, it is enough to install another, valid version of the same X1 root in your "Trusted Root Certification Authorities" – Windows will understand that it's fundamentally the same CA (due to having the same subject and public key) and will short-circuit the validation, ignoring DST entirely.

Some time later, after websites go through their automatic LE renewals (and begin sending the new, direct ISRG X1 → LE chain), cross-signing and alternate paths will no longer be part of the issue – at that point it'll simply be "the website uses a root CA which you don't have", and installing the X1 root is again the solution.

How to fix it

For most users this will likely happen automatically, through the "Automatic Root Certificates Update" feature, as soon as they visit an affected website for the first time. (For example, I just booted up a Windows 7 VM and visited one such site – while the first visit displayed an expiration error, the second did not, and "ISRG Root X1" appeared in certmgr.msc on its own.)

As of Windows 7 (or Vista?), this feature isn't part of Windows Update (the roots are downloaded on demand, they are not distributed as a standard update package), but I'm guessing you may have disabled it as well. In that case, download the ISRG Root X1 certificate from LE's website and manually import it to the machine-wide Trusted Roots store.

  • Through the GUI:

    Screenshot of the Windows "Certificate Information" dialog, showing contents of the downloaded ISRG X1 .der file, with "Install Certificate" circled in red. Screenshot of the first page of "Certificate Import Wizard", with "Store Location" option "Local Machine" circled in red. Screenshot of the second page, with the "Certificate store" field saying "Trusted Root Certification Authorities" circled in red.

  • Through command line: certutil -ent -addstore Root isrgrootx1.der

What this actually doesn't fix

Note that Firefox is listed separately because it uses neither the Windows CA store (it has the Mozilla CA Program), nor the Windows X.509/TLS code (it uses NSS and mozilla::pkix) – the version you're using already has the ISRG root built-in, independently from the OS. The same goes for Thunderbird and SeaMonkey.

It's possible that you'll also encounter programs which use OpenSSL on Windows (ssleay32.dll is a giveaway) – they typically use the "cURL certificate bundle", which is really just Mozilla's CA list repackaged as a single curl-ca-bundle.crt file. If the program is a bit old, you may have to download a new version of this file and place it in the right spot.

But if such programs use a very old OpenSSL version, or if they don't enable the "alternate chain" feature that's in OpenSSL 1.1.x, they will still have problems with websites using the DST cross-signed chain – the only workarounds are to obtain an updated version of that app, or wait it out (the DST chain will, after all, eventually go out of use).