Building trust by breaking it
We need to trust each other for the Internet to work. Ironically, sometimes that means breaking trust.
A physical five-digit lock has 100,000 possible combinations. Assuming a rate of two code attempts per second, it would take someone about 14 hours to try each one. Make that a six-digit lock and you're talking nearly a week. That's called a brute-force attack. Each additional digit multiplies the number of combinations by ten. A lock with 116 digits has more possible combinations than atoms in the observable universe. Trying each one would be far beyond the reach of any computer today, let alone any person. But that theory only holds up as long as your combination has enough entropy. It needs to be something with enough randomness that nobody could calculate it or guess it. With that in mind, you'd assume nobody would pick something as obvious as 0000, so nobody tries it first.
If someone had all the time in the world, they would eventually discover the code. So when it comes to choosing a code, it must be one long enough to deter a thief from trying each one, and random enough that it couldn't be guessed in the limited time that they have.
Pretend, just for a moment, that you're an identity thief. Your victim is a powerful, highly trusted individual, and you've obtained their briefcase containing their passport. The holder of that passport could convince someone to send highly sensitive information, and to trust the response. But that briefcase is secured by a lock with 116 dials. Impractical for a computer, impossible for a human. You take one look at the lock, immediately throw in the towel and leave it on a shelf.
Then, 18 months later, out of boredom, you begin working your way up from 0. 1... 2... 3... 4.
For all this time, you'd assumed that it would take far longer than a human lifetime to find the combination. And yet, you accomplished it in seconds.
That analogy isn't too far off from what actually happened on 17 October 2026, when a security researcher reported that a set of highly trusted certificates relied on keys that weren't the long, random numbers you'd expect a cryptographic ceremony to produce. The smallest private key used was the number 4.
The organisation responsible is eMudhra. They're a certificate authority (CA): an entity trusted by devices to issue digital certificates that help verify a website really belongs to its owner. Like all good CAs, they have processes for ceremonies where they create these keys. It's incredibly important that nobody, not even the people involved in the ceremony, ever see the value of the private key. It was a process breakdown in one of these ceremonies that is responsible for sensitive information being put at risk.
For 18 months, nobody noticed, because everyone had assumed all the guardrails and complex processes we'd put in place would shield us from such a novice error. It may have been humanity that failed us, but it was humanity that saved us.
What fascinates me is that this incident showed how easily the trust we place in each other can be broken, and that sometimes breaking it is exactly what makes it stronger.
The Internet is built on trust
The roughly six billion people worldwide who use the Internet place an incredible amount of trust in countless individuals and organisations, whether they know it or not.
Every layer of the Internet relies on people performing rituals correctly. DNS, a vital part of the Internet which lets your browser turn "oliverhardman.com" into an IP address it can send requests to, can be tricked into giving false answers. DNSSEC is a security extension which helps to prevent that, and it wouldn't work without the key signing ceremonies conducted by ICANN. These are highly complex and take hours to complete. Every step follows a script, and although they're possibly the dullest livestreams on the Internet, they allow anyone to verify the process was followed.
And when your device reaches my website, thanks to Transport Layer Security (TLS), it trusts that the company I trust, trusts me. Yet it was this layer that failed. Certificate authorities like eMudhra hold ceremonies of their own to generate keys for their certificates, and one of theirs went very wrong.
To machines, the root of trust may be long numbers. But what underpins those numbers is the trust that we humans have in each other.
Breaking trust
I am astonished by the discovery that eight private keys used to sign some of eMudhra's certificates have been compromised. Typically, this would happen because they were stolen, but this time they were so unfathomably simple that anyone could have found them extremely quickly. Each key unlocks the capability to vouch for who a website or piece of software really belongs to.
These were supposed to be P-384 keys: randomly generated 384-bit numbers, which in decimal become as many as 116 digits. Long enough to be unguessable by today's computers. But with a code like 4, no matter how big your lock is, it won't take you long to find the combination.
To make matters worse, the certificates were cross-signed by another authority called Sectigo (formerly Comodo). It's a bit like a vouch: Sectigo affirms that eMudhra can be trusted, so even devices that wouldn't trust eMudhra on their own but would trust Sectigo will still trust eMudhra. Both CAs are trusted by billions of devices worldwide.
Historically, the consequences of an event like this would have been dire. A private key being made public should be a disaster, and all the rulebooks say so. To be clear, it's still something we should take very seriously. I certainly spent time updating trust stores across software packages and installing updates across my systems, and I've been keenly watching this all unfold on the Bugzilla thread.
Anyone who works out the right keys can pretty much issue a certificate vouching for any website they like. Devices that have received the relevant security updates will now refuse it, but a device that hasn't been updated, or doesn't check revocation, could still be fooled, provided the attacker can get between it and the real site.
4 isn't a random number, but nobody chose it either. On paper, eMudhra were doing all the right things. Everyone assumed that meant their complex processes and guardrails would prevent a mistake like this from being made. But as long as humans are part of a process, human error will always present a risk.
"During the ceremony, a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys. The weak keys were the ones published [...]. The issue went undetected for about 18 months, through two independent audit cycles." eMudhra Blog (21 October 2026)
It turns out that this step was a deviation from the normal process. One where the risks weren't properly considered and mitigated. What seemed like an innocuous procedure ended up having severe consequences.
Many are asking the same questions. Despite the deviation, the ceremony still produced a working set of keys, so nothing looked immediately wrong. How did none of the guardrails catch it? And how did it go unnoticed for so long?
"There were human errors in multiple steps of the process that resulted in significant flaws in the key lifecycle integrity process for this KGC [key generation ceremony]." Naveen Kumar, eMudhra (13:43 UTC, 19 October 2026)
The most interesting part, to me, is that nobody thought it was possible for such a critical mistake to have been made by such a trusted issuer. Heck, they went through two independent audit cycles to be sure. Until recently, nobody tried basic keys just in case they worked (at least, as far as we know). We were too trusting, and that was fundamentally dangerous, because we treated that trust as a substitute for verification.
Testing trust
We all owe a huge debt of gratitude to the mysterious figure who discovered this. Identified only as security researcher "Wayne", he found the weaknesses while playing with some "new toys" and reported them responsibly to the four major root programmes: Chrome, Mozilla, Apple and Microsoft. These teams decide which authorities browsers and operating systems trust. Wayne sent his initial email at 18:05 UTC on Saturday 17 October. Chrome was investigating by 20:03, followed by Apple at 21:05, and by 21:48 Mozilla had managed to find the private keys on their own.
Certificate revocation mechanisms are one way to tell clients to stop trusting particular certificates. They're useful because they can be distributed quickly, and they allow certificate authorities and vendors to make products stop trusting compromised certificates without withdrawing trust in an entire authority, which would impact other websites they've issued certificates for. Less than 5 hours after Wayne reported his findings, the compromised TLS certificates had been distrusted in Chrome and Firefox through their respective mechanisms, CRLSet and OneCRL.
Shortly after, more certificates were revoked, and operating system updates were issued to reduce the risk as much as possible. These measures will limit much of the damage. Hopefully, anyone using Chrome, Firefox, Safari or Edge will be blocked by a warning when trying to access something "secured" by one of these certificates.
When your whole business model is about trust and nobody trusts you, you don't have a business. To nobody's surprise, on 22 October eMudhra announced they are exiting the global TLS certificate business.
The incident serves as an important reminder to us all about just how fragile the Internet can be. But the damage was far smaller than it would once have been.
The part I find the most amazing about this whole incident is seeing the protective measures come to light and industry peers (arguably competitors) working together to limit the damage. It's extremely rare for a certificate authority to mess up this badly, so it can be difficult to know how effective these measures will be in a real-world scenario. When their opportunity to be tested came, they held up, and barely anyone noticed. I suspect that's why the mainstream press focused instead on a big cyber security incident involving PHP that was happening at the same time. The quiet is undoubtedly because of the people who put in long hours to protect us.
Building trust
It's easy to assume this was just big companies protecting their bottom lines. But beneath all this are people who saw danger coming many years ago and acted then to protect us today. Looking back to 2011, serious CA failures were more common. Only months after a certificate reseller was hacked and issued certificates for popular websites, another certificate authority called DigiNotar was hacked and issued hundreds of fraudulent certificates, famously targeting Iranian Gmail users.
Back then, we couldn't flip a few switches and almost immediately shield a large portion of the Internet. The modern mechanisms we have for revoking certificates in browsers weren't around yet. We had to write, build and gradually roll out software updates, hoping users would take the time to actually install them, knowing they wouldn't understand why they were needed. Proposals were pushed through to standardise Certificate Transparency: public logs of every certificate issued, so that wrongly issued ones can be spotted and devices can refuse ones that were never logged. The people behind the actions of the past were motivated by more than financial or business resilience; they'd seen what impact such breaches were capable of having on real people.
But we can't sit still. There are so many lessons that can be taken away to build and improve processes. While we're still learning the details about exactly what went wrong, we know the outcome, and we know there are things that could've been done to catch it earlier.
Unfortunately, I'd bet that today, somewhere out there, is a person sitting in a coffee shop with their fake public Wi-Fi hotspot on, waiting for innocent victims to connect so they can intercept traffic through a man-in-the-middle attack. There are still plenty of vulnerable targets, like older Android devices, many desktop apps, and software packages relying on trust stores like certifi.
It would be foolish of us to assume that such an event could never happen again. For 18 months, a lock sat on a shelf and nobody tried an obvious code, until one stranger started playing with some "new toys". It is because of how quickly people responded, no doubt staying up all night to triage it and protect us, combined with the innovation of the past, that my trust in the open experiment that is the Internet continues to grow. That is, as long as we keep checking each other's work.