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

I just added one more reason why I don't like Apple.

This error only happens with iPhone and MacOS users

1 Like

Have a look at:

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 to check my certificates, before and after renewing, to verify if the DST X3 chain was removed.


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


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


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

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 ("" 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 ' trust anchor for certification path not found'

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

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


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'

Will have the same effect I described here


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.


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:


For anyone working with Python 3.6, you'll also want to remove the DST Root CA X3 cert from the cd /Library/Frameworks/Python.framework/Versions/3.6/etc/openssl/cert.pem file.

Found this here: macos - How to make Python use CA certificates from Mac OS TrustStore? - Stack Overflow


Among the many sites that don't work, one example is "". Here's the error:

Your connection is not private

Attackers might be trying to steal your information from (for example, passwords, messages, or credit cards). Learn more


To get Chrome’s highest level of security, turn on enhanced protection

1 Like