Two certificate authority incidents in under three weeks, and why the trust behind your own logins shouldn’t depend on either one.

What happened at eMudhra

On Saturday, October 17, a security researcher reported to the Chrome Root Program that the private keys behind eight eMudhra intermediate certificate authority certificates had been compromised. The keys had been generated with too little randomness. Anyone could recompute them from the public certificates and use them to forge an HTTPS certificate for any website, accepted by any client that still trusted those CAs.

How little randomness? A key of this type should be a number more than 100 digits long. Each of these was smaller than 256. Scott Helme, who recovered all eight on his laptop in under a second, put it plainly: “One of eMudhra’s certificate authority private keys is the number 4.” Another was 56, and another was 115.

A CA private key should be a number more than 100 digits long. Three of eMudhra’s were 4, 56 and 115.

Nobody had to steal anything. In Helme’s words, “The key was effectively public from the day the certificate existed.” The certificates were generated in April 2025, so for about 17 months the keys were there for anyone who thought to check. eMudhra says only one of the intermediates was put into production and none issued certificates to customers. Whether anyone else recovered the keys in that time is not known.

The browsers did their job

The response from the browser vendors was fast. Chrome received the report at 18:05 UTC and had blocked the eight keys by 19:45 UTC, without users needing to update or restart. Firefox blocked them the same day, Apple followed on October 19 and Microsoft on October 20, and eMudhra revoked the certificates on October 18. Google also noted that no TLS certificates chaining to the six web-facing intermediates had been logged to Certificate Transparency before the block, so none could have been trusted by default in Chrome or other browsers that require it.

Then came the longer tail. Mozilla removed trust in the root that signed the intermediates, and Google removed emSign ECC Root CA - G3 from the Chrome Root Store on October 27. On November 4, Google added that new certificates chaining to a second root, emSign Root CA - G1, will not be trusted by default in Chrome 153 and later. eMudhra estimated about 30,000 customer certificates need replacing, and on October 22 it announced it would leave the global SSL/TLS certificate business.

Seventeen months of exposure, then a hundred minutes from report to block in Chrome. The tail of root removals ran into November.

Browsers are the best-maintained part of this system. The harder question is everything else. Cloudflare, which had to patch proxies, client apps and base images, described the risk directly: with these keys, “an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic.” Apps, servers and devices that carry their own certificate lists, or never check revocation, stay exposed until someone updates them.

A different kind of incident at DigiCert

On November 5, DigiCert disclosed a data breach of a very different kind. A February 2025 server migration exposed an internal business system to the internet, and an unauthorized account read archived customer records between June 27 and July 2, 2026. The records included names and business contact details and, for some customers, identity documents such as passports and driver’s licenses. DigiCert says its certificate authority systems were not compromised and that issued certificates remain secure.

Nothing about that breach lets anyone forge a certificate. We mention it because it is a reminder of what a certificate authority is: a company running ordinary business systems, staffed by people who make ordinary mistakes. eMudhra traced its own problem to a faulty script in its key ceremony that created a second, weaker set of keys, and to staff picking that set because the labels looked alike. These are not exotic failures.

The trust you inherit

Every HTTPS connection your browser makes rests on the assumption that none of the certificate authorities it trusts will issue a certificate to the wrong party. You did not choose those authorities, and most people could not name one. When one fails, the fix depends on vendors acting quickly and on every device actually getting the update.

For the public web, that is the right trade. A website has to be reachable by strangers, and with Certificate Transparency and fast browser response, the system works far better than it used to. But it is an odd foundation for proving who you are to your own computer, your own servers or your own front door. Those relationships are between devices you own. There is no reason a stranger’s key ceremony should be part of them.

How we built around it

When you pair your phone with a computer in Allthenticate, the two devices exchange certificates and each one stores the other’s. From then on, every assurance message between them, the ones that say “this phone is here” and “this person approved this login,” is signed, and the receiving device checks that signature against the certificate it pinned at pairing. It never asks a public certificate authority. A forged certificate from eMudhra’s keys, or from any other CA, is not something either device will accept, because neither device is looking for one.

Left: the browser trusts whoever a CA vouches for. Right: each device checks signatures against the certificate it pinned at pairing, so a forged CA certificate has nothing to attach to.

Passkeys bring a related property to the web. A passkey signs a fresh challenge from the site, the signature is bound to the site the passkey was created for, and the private key never leaves the phone’s secure hardware. A look-alike domain gets nothing, and there is no password or reusable secret for anyone in the middle of the connection to collect and replay tomorrow.

Because the same phone is the key for desktop login, SSH, SSO and doors, all of those decisions rest on keys you paired yourself rather than on whichever certificate authority had a bad month.

What to do this week

• Update operating systems and browsers, then look for the things that carry their own certificate lists: container images built before the fix, appliances, embedded devices and language runtimes.

• If any of your sites use certificates chaining to emSign ECC Root CA - G3, replace them now with certificates from another CA.

• If you submitted identity documents to DigiCert for validation, watch for its notification.

• List the logins in your organization whose security depends on the public CA system, and ask which of them actually need to.

If you want to see what logging in looks like when the trust lives between your phone and your own machines, download Allthenticate and pair a computer. It takes a few minutes.