Help thread for DST Root CA X3 expiration (September 2021)

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

@jp1839
Have a look at:
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/

1 Like

What is the chain being served now?

1 Like

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

Found my issue. Had apache configured with just

SSLCertificateFile /path/fullchain.pem
SSLCertificateKeyFile /path/privkey.pem

Need to change that to
SSLCertificateFile /path/cert.pem
SSLCertificateChainFile /path/fullchain.pem
SSLCertificateKeyFile /path/privkey.pem

2 Likes

Sorry to post on a more technical thread guys ... if there's another forum you'd recommend for average users like me, happy to try there.

1 Like

That should probably be just chain:
SSLCertificateChainFile /path/chain.pem

1 Like

@John98
Can you provide the actual domain name?

1 Like

Are you running Apache older than version 2.4.8?

1 Like

Hello everyone,
we are facing a problem in our Symfony application in our docker infrastructure ("www.bilik.fr" Domain).

It provide from Nginx, but after restart and update it, the problem persist.
We use traefik for routing and letsencrypt to generate the ssl certificat.

Our other application with subdomain and same certificat works perfectly.
Any idea ?

1 Like

We were experiencing the exact same issue! We have several domains/sub-domains hosted in IIS (through Plesk). All of them with Let's Encrypt Certificates. Majority of the devices in use run Android 7.0. None of our clients could use our apps today due to the error 'java.security.cert.certpathvalidatorexception trust anchor for certification path not found'

Here is a chain for one of the certs (shortest chain?):

Certificate chain
0 s:CN = foobar.site
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

Seeing as we don't have full access to Plesk, and our hosting company not really knowing what is wrong, we had to settle for issuing ZeroSSL certificates. It fixed the problem (obviously), for now. ZeroSSL is not exactly free after generating 3 certificates, so our hosting company needs to look into this :frowning:

2 Likes

That's the conclusion I've come to as well it's using X3 instead of X1 and Univention is not using certbot and I haven't figured out how to change the root yet.

1 Like

In traefik 2 you can set preferredChain: 'ISRG Root X1'
https://doc.traefik.io/traefik/https/acme/#preferredchain

Will have the same effect I described here
https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/409?u=dmaehler

2 Likes

Yes, still running Apache 2.2.

And swapping chain.pem instead of fullchain.pem does work, SSLLabs no longer complains of extra certs in the cert chain.

2 Likes

Then it makes sense to use SSLCertificateChainFile indeed. As it has been deprecated since 2.4.8. But for 2.2 you still need it :slight_smile:

1 Like

Thank you for this warning. We're not really sure what to do now. Luckly for us, the domain with the problem is our development environment, and not the production one. I'm keeping an eye out on the WinAcme repository so if anything shows up I'll be sure to reply to this topic.

1 Like

There is a workaround for old clients (e.g. OpenSSL 1.0.x on Debian wheezy) that cannot connect due to the expiration:
You can remove DST Root CA X3 from the systems ca certificates.
Details for Debian based Linux systems: https://www.kobelnet.ch/2021/09/30/old-lets-encrypt-root-certificate-expiration-workaround

2 Likes