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

The last cert in fullchain.pem created by certbot still contains the ISRG Root X1 certificate with issuer http://apps.identrust.com/roots/dstrootcax3.p7c, which is still the expired DST Root CA X3 certificate.

2 Likes

@nyet
I'm confused...
Whom are you speaking to/with/about?
OR
How can I help you?

FYI: That is the same cert trust path that this forum is using.

openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org
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 = community.letsencrypt.org
verify return:1
---
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
---

[which was put their to ensure that older Android devices would still have access]

2 Likes

ssl - Unable to `openssl verify' letsencrypt certificate - Stack Overflow sums up the problem.

1 Like

Certbot issues a fullchain pem which will not verify

$ openssl verify -CAfile fullchain.pem fullchain.pem
fullchain.pem: O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 1 depth lookup:certificate has expired
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup:certificate has expired
OK

The last cert in fullchain.pem is the ISRG Root X1 cert issued by the expired DST Root CA X3, so verify will always fail unless it is removed from fullchain.pem.
I think certbot should not be appending it to fullchain.pem, or you issue a note to not serve fullchain.pem by nginx or apache etc.

Or suggest a way where fullchain.pem can be verified in an automated fashion (e.g. in CI) using opensssl which works with all other certs, otherwise CI scripts (or monitoring scripts) that use openssl verify have to add a letsencrypt exception

1 Like

I use both nginx and Apache and they have no trouble serving that trust path.
Your client is the one with the "problem".

As shown above, even this forum serves that exact same fullchain,pem:

openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org
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 = community.letsencrypt.org
verify return:1
---
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

And if you use openssl verify -CAfile fullchain.pem fullchain.pem on the response, it will tell you the last cert has expired, and shows an error.

We use openssl verify in CI (and in monitoring) to detect bad/expired certs. Is there a better one liner?

1 Like

@nyet

This is now a know problem that the entire Internet is working on.
There are some workarounds.
I think one is to use -trusted_first
I would also try using -partial_chain
And, of course, to update/patch the OpenSSL.

2 Likes

Apparently it's a problem with browsers caching the old R3 certificate. It seems to me that as long as it's there a browser may or may not use it.

I'm using several Let's Encrypt certificates and when viewed on the latest Chrome (MacOS 10.13) most of them work and display ISGR, but some don't and display R3 (I just updated one of these and it didn't improve the situation).

3 Likes

Have latest openssl on linux, but -partial_chain seems to work. thank you!

Unfortunately, MacOS sucks, as usual:

$ openssl version
LibreSSL 2.8.3
2 Likes

I'm in the same boat with Chrome using windows 7. Did you mange to find a fix? Thanks

1 Like

For those it might concern, ZImbra fix the tutorial for installing LetsEncrypt certs here: Installing a LetsEncrypt SSL Certificate - Zimbra :: Tech Center
Thank you.

3 Likes

THANK YOU!!!

Ubuntu 14

sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt

nano /etc/ca-certificates.conf

Remove the line

mozilla/DST_Root_CA_X3.crt

sudo update-ca-certificates

Sorted!

5 Likes

Thanks for the Zimbra link. I gleaned from there that I can use fullchain.pem in Nginx and that fixed the problem for me in Chrome on MacOS 10.13.

3 Likes

Yes, ca.cer contains it too. I even forced cert renewal (I use acme.sh) but it's still there. Why would Let's encrypt include there a CA cert signed by an expired root CA?? As long as the client has that expired root CA in their trust and the server sends that useless intermediate cert, that makes it fail in some software. I checked on Debian Stretch for example - funnily enough curl would not even connect to Let's encrypt own API and acme.sh won't renew any cert unless you stop trusting DST Root CA X3.

1 Like

We're still getting reports from some clients that they can't connect. In those cases Chrome on Windows 7 does not get the new root cert. Our cert path ist X1 -> R3 -> Our Cert (short). Of course it is not possible to install the cert manually on every client and the fear is that clients can't connect that don't contact us with the problem. Is there any other solution? Why is this not a bigger issue?

1 Like

Even it this is not a server issue I have had to fix these on server both Windows and Linux which use Lets encrypt certificate. For Windows 2008 and 2021 it was easy, just reboot server and Windows will send correct chain. For Linux / Apache I had to remove last BEGIN CERTIFICATE entry from /etc/letsencrypt/live/<mysite/fullchain.pem and do "sudo service apache2 reload".

Otherwise clients will see two paths on certificate one valid and one not valid. And for unknown reason they pick the old not valid chain and claim certificate is not valid.

These crossigned certificates were similar problem at spring with the Sectigo root certificate.

And it was similar headache to find a fix for these clients. This fix should be on Lets encrypt page.

2 Likes

Hi All,
After expiring DST Root CA X3, we are getting ssl error on chrome browser as the site is not secure but the same thing is working fine on Mozilla firefox.

can anyone have an idea how we can fix it for the chrome browser?

1 Like

We're using the new certificate chain, but it appears older devices that still have DST Root CA X3 in the certificate store are failing to validate the cert.

Is there an alternative certificate chain that can be used, if we're unable to get all end users to remove this from the store? and ensure ISRG Root X1 is present.

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

1 Like

Hi,

^^
I also had to "fix" server even it was clients problem due the same reasons.
depending on your server, if Windows reboot seems to magically fix it, if its Linux remove last BEGIN CERTIFICATE entry from /etc/letsencrypt/live//fullchain.pem, then reload your web server and then it will only send the valid certification path

1 Like

Hi guys, this is all a bit out of my depth, so please bear with me...I am a reseller and the biggest issue is that none of my clients can receive or send emails anymore, due to the SSL issue through secure ports (and I can't reach the clients either because of this of course...)

The screenshot shows in what I see in cPanel for all of the accounts.

I have been contacting my ISP (Scala hosting) and they keep saying they have done all they need, but that they are waiting on Let's Encrypt to fix this. However, it seems that people have found solutions here, so I am stuck in the middle and frustrated to potentially lose clients because of them not being able to send or receive emails and their websites not being available with SSL anymore. Thanks for pointing me in the right direction!

1 Like