Thank you so much. That knowledge will help me a lot!
Answer 1: I'm not able to connect directly to the client devices, but I have disk images of all the SD cards that I have been sharing with the devices. So I'll be able to test this with identical example devices.
Answer 2: No, not old-Android clients.
So I can test it with different versions of my disk images on an example Raspberry Pi to see if the test URL will work or not. If it works, I can configure the server and test the functions in reality.
After that I'll be able to make decisions on how to get rid of the change. Of course my best wish is that the test will give green light for the alternate chain. If it will work, I won't have to worry about updating the clients, but just configure the server.
Thanks again for your very practical answer. We'll see which one of the options you told will work.
Thanks. I's great to know this before even starting my own tests. It seems positive, and I hope the results will be same on all the versions that I'm using.
Hi there! I'm wondering if it's possible to issue a certificate with the "old way", like "End-entity certificate ← R3 ← DST Root CA X3" instead of current longer default chain.
We started seeing the errors on clients once we switched to the newer cert using "End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3". While we were able to mitigate this by using the older cert that still uses "End-entity certificate ← R3 ← DST Root CA X3" way, that older cert will expire at one point and we are now unable to renew the cert without X1 way. If we were able to issue a new cert with the old way, we can buy some time to be prepared for X1. Thanks!
While you can't have a certificate issued the old way, you can have a script "build" an old-way fullchain certificate by simply having a default chain certificate issued then putting the first certificate of that chain (the end-entity) and the old R3 intermediate certificate in a file together in that order. By definition both the new and old R3 intermediate certificates use the same private key for signing and thus are interchangeable for certificate verification.
Thanks for a quick answer! Just to make sure that I understand this... when I issue things right now, I get something like the following:
chain 0: CN: R3, Issuer: X1
chain 1: CN: X1, Issuer: X3
What you're suggesting sounds like:
not use the chain provided during the issuance, and use the lets-encrypt-r3-cross-signed.pem that you shared with the link (which is CN: R3, Issuer: X3)
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.
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:
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.
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.
Hi
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!
