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
I just added one more reason why I don't like Apple.
This error only happens with iPhone and MacOS users
1 Like
2 Likes
What is the chain being served now?
2 Likes
For those who have servers running on Ubuntu, with Certbot managing certificates, I have forced the renewals using ISRG Root X1, this way new certificates doesn't contain the chain of DST Root CA X3, and this did the trick for us.
To do that, first check if your certbot version is < 1:
sudo certbot --version
if so you have to remove it and reinstall using snap:
sudo apt-get remove -y certbot python3-certbot-apache
sudo snap install certbot --classic
sudo ln -s /snap/bin/certbot /usr/bin/certbot
After reinstalling, or If your certbot version is > 1, force the renewal:
sudo certbot renew --force-renewal --preferred-chain "ISRG Root X1"
I also have used this site https://www.digicert.com/help/ to check my certificates, before and after renewing, to verify if the DST X3 chain was removed.
11 Likes
Yes, I've tried restarting several times alas, but still getting the issue. The error message reads the same for different sites:
" Your connection is not private
Attackers might be trying to steal your information from (SITE ADDRESS) (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID"
1 Like