The problem is not the expired root CA DST cert although I know a lot of people think it is. The problem is that the intermediate R3 cert that is supplied by LetsEncrypt with even new certificates was deliberately cross-signed with the expired DST cert so that old antique Android clients that don’t validate expirations on their DST CA certs and don’t have the ISRG CA root in their cert store would continue to work. I already turned the flamethrower on the idiots at LE about this. Antique android clients all allow the user to override an invalid cert on their email clients, and antique android clients have web browers that are too old to render anything on today’s web. LE should have stared down the old Android users and told them to go buy new phones or to just manually override the invalid cert when the warning message pops up. Unfortunately they blinked, probably because none of them bothered testing what would have actually happened with an antique Android client.
Until such time that LE releases a new R3 intermediate cert that is ONLY signed with the ISRG CA root, buggy SSL implementations will continue to give problems with LE certs. Removing the DST root cert from the bundle does nothing because the buggy client is going to have that DST root CA cert in it’s own cert store. Replacing fullchain.pem with a new fullchain.pem also does nothing because LE didn’t change anything in fullchain.pem. Replacing the LE cert with a new one also does nothing because all LE certs are signed with the intermediate R3 cert and that hasn’t been changed either. Sorry about all this folks but it just won’t work. The problem is in the client. The ONLY time doing anything on the server would help is if the server has a really super old R3 cert that wasn’t cross-signed with the ISRG CA. (maybe SNG7 or Centos7 is like this I haven’t checked) and is handing that out and the client lacks the R3 intermediate cert in it’s intermediate cert store.
When the client is validating a cert chain if it hits a cross-signed cert it needs to use recursion to travel up to one of the root CA’s and if that CA is expired it needs to recurse back down to the cross-sign and then travel up to the other root CA to see if it’s valid. If it did that properly and hit the DST root CA it would then check the ISRG root CA and see that was valid, and then approve the cert.
To reiterate, deleting the expired DST CA cert is unnecessary if the client does it right. In fact it is not even necessary to present the intermediate or root CA certs to a modern client that does it right at all, because they are going to have the R3 cert in their intermediate cert store and the ISRG cert in their root CA store. All they will need is the LE cert itself. But admittedly they would have to be really modern and an older client that also does it right but lacks the newer R3 intermediate cert would need the server to send along the intermediate cert along with the LE cert.
On the bright side it gives a good excuse to tell users to finally pitch that old Windows 7 system but there’s a lot more stuff than web browsers that certs are used in. Such as phones.
I will point out that you can get a 1 year cert off of a number of resellers signed by a chain ending with Sectigo AKA Comodo for about $10. Your time is not worth screwing around with LE certs if you have older phones, etc. that have buggy SSL implementations.