Let’s Encrypt SSL Security Errors starting Sep 30, 2021: Your connection is not private

Let’s Encrypt provides free SSL security certificates for millions of websites.

An SSL certificate on a website enables secure encrypted communications (HTTPS) between users and that website.

Beginning on September 30, 2021, some users might have encountered a “Your connection is not private” or similar error message from their web browser when attempting to visit a website that uses a Let’s Encrypt SSL certificate.

If you manage web servers, jump to section “Web Server Workaround”…

This issue should only be experienced by a small number of users based upon their device operating system (e.g. some older Android versions), the web browser they were using (e.g. Google Chrome), and the website they were attempting to visit (e.g. if the website has an SSL certificate from Let’s Encrypt, even valid SSL certificates were failing).

Your connection is not private
Attackers might be trying to steal your information from {domain name}.

NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_DATE_INVALID

An explanation of the issue and the older user devices or systems which might be vulnerable to this “Sep 30th” issue can be found in article “Let’s Encrypt’s root certificate is about to expire, and it might break your devices”.

It has been known for some time that the initial root SSL certificate for Let’s Encrypt was going to expire on Sep 30, 2021. Let’s Encrypt has been using a newer root SSL certificate for a long time. However, some older operating systems don’t yet have the newer root certificate defined and/or haven’t been updated in a long time to receive the newer root certificate.

If the user was using a web browser that gets its list of valid root certificates from the operating system, but the older operating system version doesn’t have the updated list, then this problem will exist even with a fully updated web browser such as Google Chrome. Firefox on the other hand contains its own embedded list of root certificates and therefore doesn’t experience this problem on older operating systems.

Web Server Workaround

The problem is due to older user technology not knowing about or using the newer root SSL certificate that Let’s Encrypt uses. Most newer or updated technology has known about the newer Let’s Encrypt root certificate for a long time and therefore doesn’t experience this issue.

If you manage web servers that use Let’s Encrypt SSL certificates, you might consider trying the following workaround or fix.

Workaround Assumptions

Here’s our experience with this today — Your experience may vary:

• It appears that some servers will cache the list of known root and intermediary SSL certificates and only load them into cache when the server boots.
• It appears that when these certificates are loaded into cache, any expired certificates are not loaded into the cache.
• There are two intermediary certificates listed in the Certificates list that Let’s Encrypt uses: one has an Oct 29, 2021 expiry (R3 / DST Root CA X3), one has an expiry on Sep 15, 2025 (R3 / ISRG Root X1).
• Make sure the ISRG Root X1 certificate and the Let’s Encrypt Intermediate Signed by ISRG Root X1 are installed in your OS (see Chain of Trust).

The Workaround

This is going to sound funny and at first I thought our technical specialist was kidding. But all we ended up doing (after lots of research on this issue), was to simply reboot the server OS. When it came back up, it ignored the expired intermediary SSL certificate, and that let the other certificate (which wasn’t expired) be used for all Let’s Encrypt website certificates.

Really. That’s all we ended up doing was rebooting the OS for all of our web servers and then this obscure issue for a small percentage of users using older technology, stopped occurring.

We used various SSL Checker tools before and after rebooting to verify that:

• Before the OS reboots, the web servers were providing both certificate paths to the user device, but the older technology wasn’t able to fail on one path and retry using the second path.
• After the OS reboots, the web servers were only providing the one certificate path and the older technology was thereafter happy.

I cannot believe that “just reboot it” was the solution! *sigh*

Disclaimer

This is what happened for our servers in our hosting environment. It might not work or be applicable to your situation. Do your own research to determine what might apply to your own circumstances. Use at your own risk.