The Padlock Is a Promise, and Somebody Else Had the Pen
Eight certificate authority keys were recoverable from public data for 17 months. The useful story is who decides who gets to vouch for a website.
The little padlock in your address bar is not a lock. It is a receipt saying that somebody your browser trusts has vouched for the server on the other end. In October 2026, eight of those vouching keys turned out to have been recoverable from public data since April 2025, because of a bug in a key generation ceremony. The browsers blocked them inside 72 hours, which is impressive and also raises the question nobody asks out loud: who decided they get to? And what about all the software that never checks whether anything was revoked at all?
Prefer it read to you? Zara does voices now (11 min).
Zara is a character and this voice is synthesized. Mathieu Kessler, the human behind Talk Nerdy to Me, writes and fact-checks every word.
You type your bank's name, hit enter, and a tiny padlock appears next to the address. You have never once stopped to ask what it is claiming. Nobody has, and the padlock was designed that way, boring enough that you stop seeing it.
What it actually claims is much narrower. Somebody your browser trusts has vouched that this server is who it says it is, and that is the whole guarantee. Safety, honesty, and whether your money is in good hands all sit outside it.
Every interesting question lives inside the word "somebody".
The chain of vouching, in words humans say
Your browser ships with a list. Not a metaphorical list. A literal one, compiled into the software, of organisations permitted to vouch for websites. These are certificate authorities.
When a site hands over its certificate, your browser walks backwards. This certificate was signed by that one, which was signed by that one, and so on until the trail arrives at a name on the list. If it arrives, you get the padlock. If it does not, you get the warning page with the colours designed to make you feel vaguely accused of something.
The organisations in the middle of that trail, the ones doing the everyday signing, are called intermediate certificate authorities. They are load-bearing and almost entirely anonymous. Most people could not name a single one.
An intermediate's private key is, functionally, a pen that writes signatures browsers believe. Whoever holds that pen can write a certificate for any hostname they feel like, and the trail still leads home to the list. Modern browsers apply a second test on top of that one, which matters a great deal later.
Which raises the obvious question. What happens if the pen is lying on the pavement?
What happened
On 20 October 2026 a disclosure site went up describing exactly that. The private keys of eight eMudhra intermediate CA certificates are compromised. Those eight chain back to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs, and by a long tail of smaller trust stores downstream.
The original reporter, identified on the disclosure site as Wayne, did not write a paper about it. The proof was a single message, signed with each of the eight private keys and sent to the root program teams on 17 October. The message was:
We have a problem here - Wayne
That is a very economical piece of proof. Producing a signature like that takes control of the private key, so the message is not a claim that the keys are exposed. It is a demonstration. Eight signatures, eight keys, nothing left to debate about whether it is real.
Now the cause. The keys were generated incorrectly by the CA, in a way that lets anyone recover the private key from the public certificate. Public. Certificates are published on purpose, so that anyone can inspect them. Nothing had to be stolen here. The flawed generation left the private key derivable by anyone who thought to try, and the material they needed was already published.
eMudhra's own account, filed on Mozilla's incident ticket, is that a bug in the script used during the key ceremony created a second, weak key pair on the hardware security module, and because the names of the two were similar, human error led to the wrong keys being used for the certificate signing request.
A formal process, built to be careful, produced a spare set of keys with a confusingly similar name, and the wrong one went forward.
The window opened when the certificates were created in April 2025. About seventeen months. The eight break down as six TLS issuing CAs, covering domain, organisation and extended validation, plus two code-signing authorities. All eight were cross-signed by Sectigo's AAA Certificate Services root in May 2025, which only widened the set of places where that trail terminated successfully.
The part the coverage skipped, one: who actually decides
Not a government. Not a treaty. Not a standards body with enforcement teeth.
The browser makers run root programs, and they decide who is on the list. There is no further layer underneath that.
As of October 2026, the sequence runs like this. Wayne reports on 17 October. Firefox and Chrome block the certificates the same day, Chrome via a CRLSet update that evening and Mozilla via OneCRL a few hours later. Apple blocks on 19 October, the same day downstream trust stores are told so they can move. Microsoft blocks on 20 October, and on that day Mozilla announces publicly and ships an update to its cryptographic library removing the eMudhra root, while Chrome confirms the root is going into version 43 of its root store.
Four of the largest trust stores, each acting independently, inside seventy two hours of a cold report from one person.
This is the closest thing the web has to an immune system, and you were never meant to see it. It is also a small number of private companies exercising a great deal of discretion over who the rest of us end up trusting. The response was fast. The mechanism is unelected. Neither fact cancels the other.
The honest bit: was anyone actually attacked?
Nobody knows. And the not knowing is the story rather than a hole in it.
There is a system called certificate transparency. Public, append-only logs that record certificates as they are issued. Chrome, Firefox, Edge and Safari all require a certificate to show up in those logs before they will accept it. A forged certificate that was never logged is a certificate those browsers refuse.
No certificate transparency log entries have been found for these intermediates across the period in question. The disclosure treats that as a strong indication that clients enforcing transparency were not attacked by this route, and it is the best evidence pointing in either direction. If you have been browsing in an updated mainstream browser, this is the paragraph you were looking for.
But certificate transparency is a browser habit, not a law of physics. An enormous amount of software speaks TLS and never asks the question. Whether anyone found these keys before Wayne did, and did something with them outside the browser ecosystem, is genuinely unknown. Anyone telling you otherwise in either direction is guessing.
The part the coverage skipped, two: "revoked" does not mean "stops working"
This is the one I would tattoo on the industry if it would hold still.
Most software that is not a browser does three things that matter here. It trusts a bundle of certificate authorities sitting in a file on disk. It does not check whether a certificate has been revoked, because revocation checking is off by default. And it does not check transparency logs. That covers curl, Python, Node, Go, Java, git, and roughly every package manager you have ever waited on.
Scott Helme, who published the technical analysis, ran exactly this test. The setup was a local server holding a certificate for a high-value hostname, connected to with default settings. curl reported the certificate as verified. Python completed the handshake without complaint. Node reported the connection as authorized. Helme reports the same result on every Linux and macOS machine tried.
That is after the certificates were both blocked and revoked, and those are two different events. The root programs block, which is a browser mechanism. The CA revokes, which is an announcement. Neither one reaches software that was never listening for it.
So the fix is not "the CA revoked it, we are done". The fix is updating the trust bundle on every machine that has one, a category that includes build servers, containers, embedded things, and that one script from 2019 nobody admits to owning. There is no completion date on that work. There is barely a start date.
Then there is the tier below that: devices that cannot be updated at all. Routers, printers, televisions, anything with frozen firmware. They will keep trusting these certificates until they expire, in July 2039. Counting from October 2026, that is around thirteen more years of hardware being confidently wrong.
One more thing, stated carefully
Helme reports that after publishing, an AI agent recovered the private keys from a single prompt. That is Helme's own test and Helme's own claim, and I am not going to inflate it into a statement about machines being magic.
What it tells you is narrower and more unsettling. Once key generation went wrong in this particular way, the distance between the public certificate and the private key was short enough that recovering it barely counted as work.
So what, if you are not a security engineer
Update your browser. Genuinely, for ordinary browsing, that is most of it. The padlock is not broken and the web has not fallen over.
Beyond that, three things worth carrying around.
The padlock speaks to identity and nothing else, vouched for by a third party you did not choose, from a list you have never read.
Trust on the internet is a human institution. It runs on scripts, vaults, ceremonies, and the eternal risk that two things with nearly identical names end up in the wrong order.
And if you own anything that fetches over HTTPS on a schedule and has been quietly running for years, somebody has to go update its bundle of trusted authorities. No alert will fire. It will keep working perfectly either way, which is precisely the problem.
Eight keys. Seventeen months. One message, signed eight times, by someone who could have done almost anything else with them.
What else is still working perfectly because nobody ever told it to stop?
Sources
The disclosure itself: the eight compromised eMudhra intermediate CA certificates, the signed message sent to the root program teams on 17 October, the blocking timeline across the four root programs, and the absence of certificate transparency log entries: the eMudhra key compromise disclosure site, 20 October 2026
https://emudhra.we-have-a-problem.com/
The technical analysis, including the local client test in which curl, Python and Node all accepted the certificate with default settings, and the note about an AI agent recovering the keys from one prompt: Scott Helme, "Eight Bits of Trust", 20 October 2026
https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
eMudhra's own account of the key ceremony: the script bug that created a second, weak key pair on the hardware security module, and the similar names that led to the wrong keys being used: Mozilla CA incident ticket, bug 2083449
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
More Where This Came From
Plain-language translations of the machinery and the money behind the tech headlines. No hype, no vendor agenda, and a standing habit of saying what the evidence does not cover.
Related Posts
The Photo That Can Prove It Is a Photo
Apple's new iPhones can sign a photo inside the camera sensor, an industry coalition prefers a label that travels with the file, and two hobbyists hid the seal in the pixels. All three can prove where a picture came from. None of them can say what was in front of the lens.
Everybody Built a Robot Shopper. Nobody Agreed Who Has to Let It In.
In September the web's two answers to the robot shopper were visible at the same time. Shopify's default enrols merchants in AI channels that do not exist yet. Amazon blocked Meta's agent and then said why. The agent, in a test published on 9 September, could not order a pizza. In another, published on 28 September, a reporter booked a table through it, after handing over login information.
The Spacecraft That Will Ignore Its Own AI
AstroForge is about to put a transformer model on a spacecraft and then ignore everything it says. That is called shadow mode, it is the honest way to test something you cannot afford to get wrong, and there is exactly one thing it can never prove.