Stale/cached information...
The trusted root store is out of date...
It's a Thursday...
It's the last day of the month...
2 Likes
Is there some way of getting an X1 cert back? We've lost access to hundreds of remote clients that are using lets encrypt. All stopped communicating but will reboot in 8hrs.
If there is s way to get X1 back, even for a day or two, we could send a new firmware update to all of our customers devices.
1 Like
Travel back in time...
[fool them by setting their clocks back]
2 Likes
i don't undestand for fix we need to wait ?
or we nee to edit on our webserver ?
1 Like
Did anyone get a solution? Why do some devices insist on accessing through DST Root CA X3?
1 Like
Are you seeing this with any particular devices? My issues are with Apple Devices. Windows machines running most browsers seems to be working fine for me.
1 Like
There are several possible reasons.
The one that is probably the likeliest is that the web server is NOT sending any chain information.
Which leaves the client devices to fend for themselves - and they don't all come to the same conclusion.
2 Likes
Thanks Phil. So I edited /usr/local/etc/letsencrypt/live/foo.example.com/fullchain.pem to remove the last entry and now I get the chain you say is correct.
What had I done wrong to have that 3rd item in there in the first place? Or is its presence normal but only problematic for some clients?
1 Like
I have forced renew my certificate, but there is still DST Root CA X3 in chain.
SSL Certificate Checker reports:
| Issuer | Common name | Organization | Issued | Expires |
|----------------|----------------|----------------------------------|--------------|--------------|
| R3 | mydomain.tld | NA | Sep 30, 2021 | Dec 29, 2021 |
| ISRG Root X1 | R3 | Let's Encrypt | Sep 04, 2020 | Sep 15, 2025 |
| DST Root CA X3 | ISRG Root X1 | Internet Security Research Group | Jan 20, 2021 | Sep 30, 2024 |
| NA | DST Root CA X3 | Digital Signature Trust Co. | Sep 30, 2000 | Sep 30, 2021 |
1 Like
Can you use Certify the Web to include the full chain with the cert? That's what I keep seeing as the solution to my issue, but I can't find a way to do it.
1 Like
Yes, problematic.
2 Likes
Wow, so many posts, it's impossible to keep track of anything.
Is there some way that we could add support on our server to allow for X1?
Hundreds of remote devices have stopped communicating because of this oversight but if we could support X1 temporarily, we would be able to send an update to the devices.
Intermediate file perhaps, put somewhere in the directory structure of the /etc/letsencrypt directory?
1 Like
Force renew does nothing to change the chain - it only wastes a cert.
It's the same chain that has been served since May.
If you don't want that chain, then try removing it manually from the fullchain.pem file.
[it's the last one]
3 Likes
Do they all get their time from a known NTP server?
[hopefully one you can control]
2 Likes
No, NTP org and no remote access since nothing htps is working so they aren't communicating.
1 Like
About DST Root CA X1 having expired today, we who are facing problems with customers trying to use this chain that has expired, is there anything that can be done? Do we have to hope that everything will normalize? Is it necessary to change something in our server/api?
1 Like
If the client didn't find a new chain on its own, I don't think doing server-side interventions will yield results. What you could try to do is update your server's chain to serve only the short chain, without the expired certificate present, but clients could still have problems if they don't update the cache.
2 Likes
Ah, my chain is still appearing as:
openssl s_client -connect api.tzkt.io:443
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = api.tzkt.io
verify return:1
---
Certificate chain
0 s:CN = api.tzkt.io
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
Showing the DST Root CA X3 certificate.
I've removed the cert from /etc/ssl/cert.pem which has fixed cURL.
I'm still having issues with OpenSSL 1.0.2 and other tools that use SSL like Python.
(For context, this is on my personal laptop - a Macbook running OSX 10.13.6)
1 Like
did you find any solution? im waiting for the same answer
1 Like