Correct. You only need the new end-entity (first) certificate issued by Let's Encrypt. You can use the download I provided as the chain.
Sounds great, thank you so much! I'll try it out and see how it goes.
Don't delay on a proper fix though. This won't last too long.
One notable option for people who encounter a difficult to solve conflict regarding the certificate chain is of course to use an alternative ACME CA, of which there are now a few to choose from and in most ACME clients you can mix and match depending on your requirements. Most are summarized here: https://docs.certifytheweb.com/docs/guides/certificate-authorities#supported-cas
Most users should be happy sticking with Let's Encrypt but I wouldn't want anyone to see this issue as an insurmountable problem and I don't think LE would either.
May I ask what kind of error do the clients encounter? In theory, there shouldn't be any regression with the new chain.
Want to add the one you subsequently happened to come across this other thread?
It looks to me like their own root is valid until 2041, although it might not be that much more widely trusted directly than the Let's Encrypt roots, while they also have a cross-signature (possibly itself renewable) from Certum valid until 2023. (The Certum root that issued this cross-signature is valid until 2027.)
I have seen some comments on some Linux forums I frequent about timeout errors. Updates to my own distribution fixed some errors such one of the update servers were unreachable yet ping works.
Recent updates have done wonders for excessive storage consumption as well.
Not sure about the cross certificate idea only because of the mechanism for revoking a compromised certificate which has happened with more than a few company servers.
Hi again! I have now tested it in the oldest Raspberry Pi image that I have in production.
The disk (microSD) image with all the software was upgraded last time in the end of 2019 or in the beginning of 2020, and after that absolutely no upgrades or other changes have been made on it. The system time is the only thing that changes during the time in the device that's run by that disk image. No software as well as no certificates or any configuration has been updated / upgraded / changed. In the other words, It's been frozen after it was created.
The OS version is 10 (buster) and Wget version is 10.20.1.
When I try wget https://valid-isrgrootx1.letsencrypt.org/ , it downloads the index.html without any error messages, and accepts the certificate. -> Test result = OK!
That makes me believe that all the devices (the versions after the first one, too) will continue working after the end of September, if I just configure the server to use ISGR Root X1.
I'd like to test the change to ISGR Root X1 in the server as early as possible, of course, so that's why I started searching for some instructions on how to configure certbot properly to use ISGR Root X1. I also made a backup of the server and tested how it would work if I just type sudo certbot renew --preferred-chain "ISGR Root X1". It returned this error message:
certbot: error: unrecognized arguments: --preferred-chain ISRG Root X1
When I type certbot --version, it returns "certbot 0.31.0".
I have Ubuntu 18.04 LTS.
I searched, but didn't succeed yet to find simple instructions on how to do this with Certbot. It could be just that I have completely failed to search it properly, and also I'm unfortunately lacking a lot of basic knowledge that I should have. Have you happened to find step by step instructions where all the important things are explained to just succeed this one thing? I'd be so grateful to avoid inventing once again something that someone else has already succeeded to do.
Thank you for your kind help.
The correct command is in fact to add
--preferred-chain "ISRG Root X1" to the command line. However, your certbot version is too old to support that command. You probably need to uninstall your current version of certbot, and then install the snap-based version.
Thanks again! Now I understand why there were no upgrades available for Certbot with apt.
I am using 184.108.40.206 LTS which seems to be working fine lately
I have an IoT device running in which I have full control over and both have the DST Root CA X3 and ISRG Root X1 as trusted root certificates.
The server it access is also in my control -hence I can setup a fullchain on the server to point towards the ISRG Root X1 and the device is able to access it. However I'm a bit in doubt about the OpenSSL and potential other unforeseen issues which may appear when DST Root CA X3 expire.
Wouldn't you say if I delete the DST Root CA X3 from the root certificates on the device and I'm still able to get a secure connection to my servers - then everything should be good -even after September?
Yes, that sounds good to me. If you use the "alternate" chain on your servers that is rooted in ISRG Root X1, and your devices have ISRG Root X1 in their trust store, then the DST Root CA X3 certificate isn't involved at all so its expiration doesn't matter.
Sorry! Forgot to follow-up here, but you're correct, there shouldn't have been any regressions. However, there was a bug in our code and we weren't providing the two chains properly (only returning one chain) which was the actual cause of the issue.
griffin's workaround worked well until we figured out the bug and fixed for it, so thanks to griffin for the help!
You're very welcome.
Glad you found the issue and got it fixed.
Thank you very much for the feedback! Happy to hear that you found an fixed the bug.
We have a bunch of Windows 7 SP1 embedded terminals that does not have any updates since SP1 package, they are today accepting the Let's encrypt certificates will they be affected after September 2021?
might want to modernize your terminals, windows 7 is now over 16 months out of support
We are working on that as well and new terminals are not shipped with the same configuration, do you have any input on the question?
Well, according to the Certificate Compatibility page, anything XP SP3 or newer should work, as long as it's been getting the root certificate updates.
Can you run code on the devices? If you can connect to https://valid-isrgrootx1.letsencrypt.org/ in whatever program you're running on there, and then see that ISRG Root X1 is in the Windows Certificate Manager as a Root Certificate (assuming that's the trust store your application uses), I think you'd be alright, but it may be hard to test everything for sure.