Update: Certify The Web v5.5.4 has an automatic method to disable the expiring R3
In addition to the above, you may find that some servers do not serve the default
R3 > ISRG X1 > DST Root CA X3 chain, resulting in incompatibility with old versions of Android. To resolve this, manually install the
ISRG Root X1 cross signed to DST Root from (Chain of Trust - Let's Encrypt) https://letsencrypt.org/certs/isrg-root-x1-cross-signed.der:
- Download the .der file
- Open certlm.msc, browse to intermediate certification authorities, right-click >
Import.., select .der file types and browse to your downloaded file, then complete the import. The updated (default) chain will now be used.
Let’s Encrypt’s DST Root CA X3 root certificate and one version of it’s R3 intermediate will be expiring on the 30th of Sept 2021. The
R3 intermediate chained to
DST Root CA X3 is replaced by the
R3 chained to
ISRG Root X1.
When serving your websites, Windows builds a valid certificate chain and uses it for the https (TLS) connection. Windows currently favors the wrong (expiring)
R3 because it has a newer start date than the correct one, this is a built-in windows behavior.
Windows is expected to switch to the correct
R3 intermediate automatically but if you experience any issues with certificates suddenly being considered invalid, try a server reboot first. If a chain validation issue persists try deleting the old
R3 after it expires (the one issued by
DST Root CA X3, not the one issued by
ISRG Root X1) in the windows certificate manager:
Manage Computer Certificates > Intermediate Certification Authorities, again a reboot may be required.
DST Root CA X3 expiry, default certificate chains will be
Your Certificate >
ISRG Root X1 >
DST Root CA X3 (expired). This is because Let’s Encrypt are preserving the use of the expired root for older OS compatibility (Android 7.0 and lower, Windows XP etc). If you experience client issues with this chain you can opt to use the
ISRG Root X1 chain without the
DST Root CA X3 root. See Frequently Asked Questions | Certify The Web Docs
In the event that the above does not resolve a compatibility issue with clients you need to support, you could consider migrating to an alternative CA with a root that’s trusted by your clients. You will need to investigate which trusted roots are present in your clients trust stores and migrate accordingly. To read more about adding new CA accounts and migrating see: Certificate Authorities | Certify The Web Docs - note that rate limits do apply with all Certificate Authorities, so if you intend to migrate you should consider starting to test and migrating now.