Letsencrypt ISRG Root X1 local lookup not found

The issue is definitely the expiration of the old CA.
However, the web browser seems to pull the correct certificate from the firewall (nextcloud is behind HAproxy). It is from ISRG Root X1 → R3 → my wildcard cert.
However, the application seems to want to access some local copy of the certificate, and gets the error:
The issuer certificate of a locally looked up certificate could not be found

Issuer: DST Root CA X3

Which is of course understandable, since DST Root CA X3 doesn’t exist any more, old CA that expired.

So now, where is the certificate that the app is locally attempting to access and how do I delete it?

How did you delete the cert and where was it in your case?
I have about a few dozen clients which have to be up an running again.

I hope the NC devs will have a pretty quick look into this.

So far this is only happening for me with the Windows client and I don’t have anything special running in front of my Nextcloud server except a standard Untangle firewall. All my android devices are fine as well as the desktop app on Linux. So there’s no where I know of to delete/refresh any certificates to try and solve this.

SOLUTION (at least for me): Reboot the server

I have Nextcloud running behind a Windows IIS reverse proxy. Windows IIS is the machine serving the certificates. Running an SSL test (SSL Server Test (Powered by Qualys SSL Labs)) showed that my server was returning the wrong (expired) intermediate certs. (Apparently browsers and other software are smart enough to go download the correct certs from their origin). Looking through the certs on the machine showed only the correct new certs. Rebooting the machine fixed it, which leads me to believe Windows was serving cached copies.

Yet another SOLUTION:

I ran through and checked the SSL test site given by Mike3. I am using LetsEncrypt and I noticed that it showed two certificate paths. The #1 path was the one to the proper “ISRG Root X1” cert. There is another #2 path to the “DST Root CA X3” which shows invalid. So seems some things are following the proper #1 path and others (Windows clients) are not?

Tried restarting the web server. Still same issue.

Since it’s easy/free to renew LetsEncrypt, I just forced an early renewal for my nextcloud domain, restarted the webserver and now things are working. What a pain.

Updating Server and reboot worked here :+1:
However, i can’t tell if it was the the update or the reboot, that helped. :wink:

Solution of the problem
ca x3

Try this to disable use of the expiring R3 in your chain [Windows OS]:

Open certlm.msc from CMD (win+r), expand the tree for [1] Intermediate Certification Authorities > Certificates and for [2] Untrusted Certificates > Certificates.
Drag R3 issued by DST Root CA X3 from [1] to [2], this will disallow the expiring R3. Don’t do this for R3 issued by ISRG Root X1
Ensure you have R3 issued by ISRG Root X1 installed in Intermediate Certification Authorities > Certificates, if not you can get it from https://letsencrypt.org/certs/lets-encrypt-r3.der and install it to that store.

Check your served chain again, you may need a reboot.

Попробуйте это, чтобы отключить использование истекающего DST Root CA X3 в вашей цепочке [Windows OS]:

Откройте certlm.msc через CMD (win+r), разверните дерево для [1] Промежуточные центры сертификации> Сертификаты и для [2] Недоверенные сертификаты> Сертификаты.
Либо через поиск найдите все DST Root CA X3 сертификаты (в моём случае их 2) и удалите их.
После чего, следует проверить наличие сертификата ISRG Root X1, установленный в Промежуточные центры сертификации> Сертификаты, если отсутствувет, вы можете скачать его по ссылке https://letsencrypt.org/certs/lets-encrypt-r3.der и установить.

Возможно, вам потребуется перезагрузка. Это решение мне помогло.

I split the topic since here it doesn’t seem to be related to the expired certificate rather the new one that is not included in the local varstore. Is that something that has to be done in Windows directly? Or is there something the desktop client can fix as well since the web browser doesn’t show an error?

For this issue, there is a bug report:

Perhaps solution for linux clients and linux servers (similar problems):