Let’s Encrypt outage – Not malware, not ransomware!

Why have web certificates?

When you connect to a website using HTTPS (secure HTTP), your browser and the server use public-key cryptography to set up a one-time encryption key for that connection.

The server sends you a digital certificate containing public key to use in the process, tagged as belonging to the name of the service you’re using, such as example.com.

As long as server’s owner (or perhaps the company running the server, if it’s cloud hosted) is the only person who has the private key that corresponds to example.com‘s public key, you can set up a connection that [a] can’t easily be snooped on, providing confidentiality, and [b] can’t easily be tampered with, providing integrity.

Remember that integrity should be considered as important as confidentiality, because an attacker who can trick you into accepting encrypted data that’s been modified may still be able to cause you harm, even if they can’t decrypt that data themselves, and therefore can’t be sure exactly what changes will show up when you decrypt it.

The problem here, of course, is that anyone can create a web certificate, and can put any any name in it they like, pretending to be any server they want.

What you need, therefore, is a certificate that has been verified in some way, by a trusted third party called a Certificate Authority (CA), to reassure you that it belongs to someone who really is authorized to run a server that belongs, say, to example.com.

The way that certificate verification is done is generally very simple. The CA doesn’t send an investigator round to the site owner’s business address and demand to see the owner in person, complete with photo ID. The process is usually automated, for example by requiring the requester to temporarily insert some random content (a text string generated by the CA) at some randomly-generated URL on the web server. This is a basic way of demonstrating that the person or program requesting verification has control over the server itself. That’s generally considered sufficient “proof of authority,” on the grounds that anyone who can modify content on the site could deliberately publish malware or fake news any time they wanted, even if the official owner of the site acquired the certificate in the first place. (Remember that web certificates don’t verify or validate the content or truthfulness of a site, merely that the certificate corresponds to the name of the site it claims.)

How long should trust last?

One of the most popular CAs out there is Let’s Encrypt, mainly because it was the first CA that successfully made certificate issuing easy and automatable, and also free of charge, thereby allowing home users and small businesses to sidestep the sometimes substantial annual fees charged by the once-dominant commercial CAs.

The idea was to encourage as many people as possible to adopt secure HTTP, making web traffic in general more resistant to surveillance and criminal tampering in transit, and removing the previous burdens of annual technical hassle and unwanted bills.

Easy, automatic issuing and renewal of web certificates (renewal essentially means issuing a new certificate for an existing web service before the old one expires) has also made it possible for the online world to move to more frequent renewal, which means that public keys for which a criminal has stolen the corresponding private key won’t last as long as they used to.

A few years ago, certificate renewal was so complex and expensive that many companies paid extra to buy two-year, three-year, or even five-year certificates, turning compromised certificates into long-term gifts to any cybercriminals who could steal their private keys.

But by 2018, certificates were limited to two years; by early 2026, the maximum was 200 days; that limit will go down to 100 days in 2027 and to just 47 days in 2029.

Let’s Encrypt, with its focus on serving the community quickly and for free, was one of the prime reasons why fast-expiring certificates are now feasible.

Indeed, Let’s Encrypt itself already limits its own certificates to 90 days, and is currently getting ready to reduce this to a maximum of 45 days by February 2028, more than a year ahead of schedule.

Critical infrastructure

Let’s Encrypt now issues more certificates that any other CA , with various reports stating that the organization issues an absolute majority (i.e. more than half) of all web certificates in use, making it a critical part of our web security infrastructure.

So, when the organization announced on 2026-05-08 that it was temporarily suspending its certificate issuing service due to “a potential incident,” quite a ripple of worry spread through the internet.

Now, assuming you don’t leave it until the very last day to renew your certificates, thereby ensuring your new certificates have time to overlap your old ones, a brief issuance outage generally won’t cause you any trouble, as long as the outage doesn’t take so long to correct, or create such a bottleneck when it ends, that you miss your deadline.

But a “potential incident” could be anything from a criminal detected in the network and kicked out quickly, all the way to a ransomware attack in which data was stolen, servers trashed, and services forced offline, possibly for hours, days, or weeks.

(Jaguar Land Rover, you may recall, infamously ended up with its production lines frozen for a month, even though its IT network, not its industrial control systems, had been attacked by ransomware criminals.)

Fortunately, despite social media speculation that Let’s Encrypt’s incident could be a cybercrime intrusion and therefore might take ages to fix, the company quickly revealed that the shutdown was an operational incident.

The problem related to certificates it had issued that didn’t comply precisely with issuance rules.

There was no immediate cybersecurity danger, no network intrusion, no opening for cybercriminals to exploit, and no reason to distrust Let’s Encrypt’s staff or systems.

Why the intervention?

Greatly simplified, Let’s Encrypt created a pair of new root certificates, in part to support its move to 45-day issuance.

A root certificate is one at the top of the tree, vouched for only by itself and the accepted trustworthiness of the issuer, and trusted directly by browsers themselves to vouch for other people’s certificates.

Mozilla’s official root CA list, used as the source of trust by most browsers, many downloaders, and by default by OpenSSL on Linux, currently [2026-05-10] has 120 root certificates issued by about 50 different organizations worldwide (government, community, and commercial), from Autoritat de Certificació de la Comunitat Valenciana, run by the Spanish government, to WISeKey, run by the OISTE Foundation in Switzerland, created by the International Telecommunication Union (ITU) in 1988.

But Let’s Encrypt then realized that those new master keys weren’t 100% compliant with Mozilla’s strict rules for its so-called root store.

Those root certificates weren’t compromised, or sneakily created to support unwanted surveillance, or issued by a rogue insider at Let’s Encrypt.

The error was that they didn’t explicitly list that they were only for signing certificates intended for securing network traffic, and not for other purposes such as digitally signing software.

Mozilla’s rules require that erroneous certificates get revoked as soon as possible and re-issued in full compliance with the rules, to reduce and quickly correct any risk or confusion created by innocent mistakes.

Let’s Encrypt followed the “rules of repair” closely, shutting down certificate issuance entirely (a super-simple way of ensuring that the non-compliant root certificates could not be used while the problem was investigated), correcting the problem, and then turning their certificate issuance back on.

Total outage time?

Two-and-a-half hours.

No malware, no ransomware, no attackers in the network.

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!