So I'll start by saying I hope I'm wrong. Please disprove whatever I say next - I'll jot down my findings here anyway.
I believe there is a potential problem with the way Windows (server and desktop) performs chain building when using certificates from its local machine certificate store, which will result in certain services presenting expired chains after the R3 expiry on Sept 30th.
Specifically I believe Windows has a tendency to choose the soon-to-be expiring R3 (chained to DST Root X3) in preference to the R3 > ISRG Root X1 > DST Root X3 chain. This is regardless of your original certificate (I am definitely storing a PFX with leaf > R3 > ISRG Root X1) and I believe it happens because windows looks for "issuer=C = US, O = Let's Encrypt, CN = R3" and uses the first one it finds in the SYSTEM users certificates store (Intermediate Certification Authorities).
The end result is that services using the local machine certificate store server an expiring chain (IIS, MS Exchange, Remote Desktop services etc), rather than those using raw cert files (as .pem, .key etc). Deleting the expiring R3 intermediate from this store and leaving the newer R3 > ISRG Root X1 intermediate fixes the problem. I don't yet know if there is any process which will cause windows to automatically repopulate with the wrong R3. Generally I think the intermediates get populated upon importing a certificate that uses them, but windows does have some auto population for some events.
For a simulated client connection in the future I'm using the following on ubuntu:
Passing (presents correct chain):
faketime '2021-10-01' openssl s_client -servername beta01.projectbids.co.uk -connect beta01.projectbids.co.uk:443
Failing (presents wrong chain):
faketime '2021-10-01' openssl s_client -servername api-01.openchargemap.io -connect api-01.openchargemap.io:443
Access to view the SYSTEM users certificate store is via
psexec -i -s cmd.exe and running
I'm far from being an expert on certificate chains, or what windows is thinking. We can probably pull someone from Microsoft onto the conversation if it proves to be a big issue. If on the other hand it's easily disproven as just my mistake, then it's nothing to worry about. I thought I'd share this here in case it becomes apparent that it's a big problem.
If you have a windows based service that correctly serves it's TLS using the machine certificate store (not nginx/apache etc) and SSL Server Test (Powered by Qualys SSL Labs) or openssl reports the R3 > ISRG Root X1 chain without any extra effort then I'd like to know if the old R3 intermediate is present or not to prove if this only affects older/some installations.
I believe this also affects the client in some ways but it may only be relevant to the windows certmgr UI (which often shows R3 > DST Root X3, when other tools report R3 > ISRG Root X1). I've not yet tested from windows with the date set in the future.