Hi @nertzy, welcome to the LE community forum 
Thank you for the input; But without detail, it really doesn't say much more than a news story headline.
5 Likes
We are facing the same issues as @nertzy and have also opened issues with Heroku. Using the Heroku Ruby build pack when I check /etc/ssl/certs/ca-certificates.crt I am seeing ISRG Root X1 but not DST Root CA X3.
The domain we are connecting to show the following when I check is with openssl s_client -connect xxx:443
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.xxx.com
verify return:1
---
Certificate chain
0 s:CN = www.xxx.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
I will provide any information that is needed to help me get this resolved. Hopefully it can help others resolve this issues as well.
3 Likes
Hi @howeszy, welcome to the LE community forum
It seems that site is using the old default chain.
see post 146: Help thread for DST Root CA X3 expiration (September 2021) - #146 by griffin
If you can communicate with the site operator, they might be able to change the chain being served.
5 Likes
@rg305 thank you for the quick response. I will reach out to them immediately.
Also for anyone interested I found a response on Twitter from a Heroku Dev about this issue:
Ubuntu removed the cert from ca-certificates slightly prior, so anyone using an official Ubuntu image would have this change.
Heroku’s stack images use the Ubuntu packages verbatim, that got pulled in during our last release cycle
https://devcenter.heroku.com/changelog-items/2271
2 Likes
Notice that the chain currently used shouldn't be in use after the certificate would have renewed after May this year. So the system administrator of the site isn't using the ACME protocol properly..
8 Likes
We updated the thread in API announcements with some more information about this change and some good starting points, should it be helpful to you!
7 Likes
Hello.
Will this occur worldwide?
Also, will this affect sites that do not use LetsEncrypt?
2 Likes
Expiry happens at a particular moment in Universal Co-ordinated Time, so, yes, worldwide, and at essentially the same moment but for some people that will be in their afternoon or evening and others lunch time.
Let's Encrypt is the only large issuer whose certificates might be trusted via DST Root CA X3 so, no, other sites that don't have or rely on such certificates will not be affected.
5 Likes
Also, how long will this event last?
2 Likes
Don't blink or you will miss it!
It just expires.
No fireworks.
No parade.
No funeral procession.
Just the clock ticking past its' lifespan.
One second it is valid...
And the next second it is not.
8 Likes
I wanted to confirm this. Heroku got back to me and said the same thing. We were able to use an updated ACME client and generate a new Let's Encrypt certificate with the proper Intermediate CA included. Now everything is working as normal.
5 Likes
Yay!
They are finally doing it right:
Certificate chain
0 s:/CN=devcenter.heroku.com
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
5 Likes
Hello! Maybe someone here can help - I updated my client's SSL certs, and they look good on Windows/Android, I'm seeing the ISRG root certificate. However on ios/osx I'm still getting CERT_DATE_INVALID error, because it's still using the DST certificate, with the R3 that expired a couple hours ago. Nothing I've tried so far has convinced ios/osx to download the new ISRG cert, and I can't delete the expired DST cert (since it's not expired yet, just the R3).
Does anyone have any ideas? I'm a little desperate at this point! The client only uses macs so the site is basically down for them and they /just/ launched an eblast campaign.
1 Like
Providing a hostname so we can check to see what certificate chain your server is serving would help diagnose what might be wrong. Barring that, all we can likely recommend is restarting clients or OSes on the problem machines.
6 Likes
The certificate is for theartshow.org and artdealers.org (along w/ the www versions).
I tried rebooting my iPad and MacBook, but I'm still getting the expired certificate.
I did generate these certificates manually on a different server and then imported them using Plesk, which could maybe be part of the problem, although the previous certificates generated using the same method had been working fine for years.
Thank you for any help you can provide!
1 Like
HI @Narrowstrife, welcome to the LE community forum
[sorry it wasn't under better circumstances]
There are NO intermediate being served:
---
Certificate chain
0 s:/CN=artdealers.org
i:/C=US/O=Let's Encrypt/CN=R3
---
---
Certificate chain
0 s:/CN=artdealers.org
i:/C=US/O=Let's Encrypt/CN=R3
---
They should look like this:
---
Certificate chain
0 s:/CN=community.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
5 Likes
Ah! I entered the certificate details into Plesk wrong, which is why the intermediate certificate was missing. Everything seems to be working now. Thank you for the sanity check!
5 Likes
We use Let's Encrypt certificates and I noticed a short while ago that our sites are down on many devices. My main site is https://socialattache.com and I get a certificate error now on iPhone XS software 14.8 Safari as well as on OSX 10.15.7 using Chrome or Safari.
The certificate for this domain doesn't expire until November so it appears it's not a certificate expiry issue but likely the root certificate expiry I'm reading about. We create our SSL certificates using the Acme PHP library that we call periodically to create/update our certificates.
These don't seem to be "old" devices so I expect there's something that needs to be done on our end to get them working again?
1 Like
The Devil is in the details...
This is what your site is serving:
---
Certificate chain
0 s:/CN=socialattache.com
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
This is an example of what it should be serving (now):
---
Certificate chain
0 s:/CN=community.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
2 Likes
One question I have not yet been able to understand is how modern devices will be able to use the default string if the ISRG Root X1 certificate depends on the DST Root CA X3 certificate that will expire on September 30. It's okay that Android doesn't consider the expiration date (notAfter field) to create a chain of trust, but what about the other systems that consider that field?
1 Like