I don't really know which one he used.
It might be this one:
You'll probably want this one
Active ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) Self-signed: der, pem, txt
Beautiful, just what I needed. Thanks
The proposed solution worked for me on wind 10 with Chrome
One particular Windows 10 machine in our office is having a certificate issue.
It was getting NET::ERR_CERT_DATE_INV error, so I renewed the certificate, restarted nginx, cleared certificate cache on the client, but the error was still there.
I deleted the DST Root certificate from the client and imported ISRG Root certificate from one of the working machine and now the client sees NET::ERR_CERT_AUTHORITY_INVALID error.
I deleted the ISRG Root certificate. Same error.
Why is this one machine having a problem out of 20 or so Windows 10 machines?
Have you imported the self-signed ISRG Root X1 certificate or the certified ISRG Root X1 signed by DST Root CA X3?
Oof, finally solved the problem.
If you export the ISRG Root X1 certificate from a working Windows 10 computer and import it from a non-working computer, the import won't work.
I downloaded the self-signed ISRG Root X1 .der file from Chain of Trust - Let's Encrypt and imported it and voila, it was able to access all sites with letsencrypt certificate without errors.
So my solution for Windows client machines would be to delete DST Root CA X3 certificate, download and import ISRG Root X1 certificate.
I still don't understand why this particular client wasn't served the new certificate from the server though.
The above worked for me as well - one tip is to make sure you double click the
.der file to install it. Do not try to Import using
certmgr.msc or Google Chrome.
I'm having the same issues " Your connection is not private" on certain websites with my Chrome on Windows 7. Spent all night tying to fix it. I have downloaded the isrgrootx1.der file but what does "put it on "Third Party Root Certification Authorities"" mean and how do I do this? Thank you for your time!
Double-click the file and then click the [install] button.
Choose where to install it to and pick "Third Party Root ..."
[not my advice - simple typing for clarification]
Thanks @rg305. I found the "Third Party Root Certification Authorities" folder and installed it again. Unfortunately, it hasn't solved the problem. Thanks once again for your help though
I get a blank page at that link. Certificate is there, just no content!
No, I'm not able to access the site using the chrome browser
OK then your PC needs some tough love!
You're on Windows 7 right?
Even when Windows 10, 21H1 Version, I am unable to see ISRG Root X1 in my Trusted Store.
Visiting the site https://valid-isrgrootx1.letsencrypt.org
is also not working anymore.
Letencrypt is also being shown as untrusted website
Have you done anything on your machine to disable Windows Updates? Or used some sort of "Win10 optimizer" that tries to do things like disable telemetry and unnecessary services? Those things can break key system components like this.
If this is a corporate managed machine, corporate policies could also be to blame for the root lazy loading not working.
Bottom line, your machine is in some sort of non-default configuration that is preventing normal processes from getting the ISRG Root X1 and putting it into your Trusted Roots store. You either need to fix the configuration or manually install it with this copy (https) or this copy (http).
The issue that I've posted is reported by our end-users. We have noticed that they are using normal WIndows (not corporate-managed). In most of their devices, even their Windows Update is not reporting any updates to be installed. Are there any configuration things that we can ask them to check or is there any program that they can run to fix this?
Or is manually downloading the copy and installing it the only process?
Please suggest us a standard process that we can suggest to our end-users with this type of issue.
Our end-users do not have much knowledge in this area.
The standard process (which would automatically download and install the ISRG Root X1 cert) is broken on the affected machines. That's the problem. Unfortunately, there's not a lot of common knowledge out there regarding how this gets broken. And without knowing how each user's machine broke, you can't begin to fix their (potentially different) problems.
ISRG Root X1 certificate manually is a work around that should fix this particular symptom of the underlying problem. It can be as simple as providing a registry file that they can double-click to import the certificate such as this one. You'll have to remove the
.txt extension because the forum won't let me attach
ISRG Root X1 - HKLM - AuthRoot.reg.txt (11.1 KB)
But some users (with good reason) may not want to trust a random registry file from "some guy on the Internet". The more trustworthy instructions are also more complicated.
- Download the cert directly from Let's Encrypt here
- Install it into the Local Computer's
Trusted Root Certification Authoritiescert store, the process for which varies depending on the OS version.
Here is an example of how Windows gets certificate updates automatically. Simply open the Windows event viewer, navigate to Windows Logs > Applications, and filter through 4097 ID events to view recent updates of this type. If there are no recent events, it's likely that Windows isn't getting the updates automatically for some reason.
My Windows 10 client updated the "ISRG Root X1" certificate on 07/04/2021, but my Windows Server updated this same certificate only on "09/30/2021".
Evidently one way this gets broken is with bad proxy settings. There are separate proxy settings for the system vs the user. Microsoft has documentation at How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site.
In particular, I'd like anyone affected by this issue to run:
netsh winhttp show proxy
(from that documentation page), and report back the results.
This also seems potentially useful: https://social.technet.microsoft.com/wiki/contents/articles/242.windows-pki-troubleshooting-capi2-diagnostics.aspx