A possible fix that helped us get many customers back on track:
Many of our customers has webshops, which haven't worked since the DST root CA Expired this morning.
I have been troubleshooting through my android tablet and an Iphone. I can see in my certificate store, that ISRG CA is installed, but it's not using it on Samsung internet. However if I use my windows pc, it goes through like nothing changed.
To fix this issue, I went into IIS on Windows server, and configured the bindings. I changed it to another certificate in the binding, then pressed "Ok", then edited the binding and choose the right certificate. Then restarted the site (Not the www service!), and it worked. Now all our customers and software is back on track.
IIS -> Edit binding -> Choose another random certificate -> OK -> Edit Binding -> Choose the correct certificate -> Restart site (Not WWW service).
I don't know if there is another solution, but this helped us.
Thanks to @webprofusion for alot of answers on possible fixes, this one worked and thought I would share it in a post, so ppl won't have to go through alot of topics.
Reboot is one quick way to fix it, re-binding is the other (doesn't always work). Windows just likes to hang onto that old R3.
Yea, just seems really weird that only some devices does it. My Tablet (Android 11) had the issue, even tho it should be "older devices" (Android 7 and older). That isn't always the case.
Restarting WWW service did nothing. I haven't tried rebooting, so can't confirm that works.
But do you need to delete the expired cert, or does it delete itself ?
I still have the expired one within my certificate store, on clients aswell as the IIS server.
This issue drove me crazy for days. After the September 30th expiry of the DST Root cert the IIS server would not point to the new ISRG root cert in the certificate chain when I checked the binding. Some devices connected with HTTPS and some didn't.
I've written a short guide on how I fixed this issue here: https://timstech.blog/?p=223
Hope it can help someone
Thanks! Couple of things:
- You do not need to delete DST Root CA X3 at all, you just need to install ISRG Root X1 (Self signed) and ideally reboot to flush all cached chains with the old R3. See also Let's Encrypt DST Root CA X3 expiry Sept 30th 2021 | Certify The Web Docs [Edit: you mentioned rebooting didn't fix your problem, but it wouldn't if you hadn't installed ISRG Root X1 yet]
- Installing the ISRG Root X1 (Self signed) will immediately fix the chain shown in the windows certificate UI (on the server), but the server chain (served by IIS/http.sys etc) may persist until you reboot. Updating bindings can help, but does not always help.
- If your server needed ISRG Root X1 installed manually then it's likely also lacking the ability to update any other root certificates. Most likely either automatic root CA updates is disabled by group policy (some admins did this years ago and forgot about it) or your server cannot contact some URLs related to windows updates (i.e. if you are blocking outgoing https connections).
Thanks @webprofusion, good points.
My server managed to get the ISRG Root X1 cert automatically and install it in the Trusted Root CA. The issue for me was that it wasn't in the Intermediate CA. The reason I included installing the root cert in this guide is for the reason you mentioned - some people have this disabled, or may not have done the necessary updates in order to get it. Getting both directly from the LetsEncrypt website and installing in the correct location covers all bases
Awesome, out of interest which ACME client is this? For the ones that output PFX you'd expect the intermediates to be included in that container.
This was with Win-Acme - v184.108.40.206 on one server and 220.127.116.11 on another. Both Windows Server 2016 and both had the same issue.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.