eMudhra weak keys: what Cloudflare found and what to do

Cloudflare says eight intermediate private keys held by the certificate authority eMudhra were trivially weak, making them recoverable from the public certificates themselves. The Cloudflare Blog reports the tiny keys included values that should not have been chosen for a 115-digit private number, and that forged certificates appeared within hours after the weakness became public.

What Cloudflare did and what they saw

According to the Cloudflare Blog, the company patched high-priority systems the same day the issue was reported. They patched customer origin-facing proxies called Pingora within hours so those systems would reject the vulnerable eMudhra keys. Cloudflare also ran an AI-assisted review of their source code and produced a list of systems that trusted the weak keys, assigning tickets and patching the highest-risk items first.

To detect active misuse, Cloudflare added logging to Pingora to note when a server presented a certificate signed by the weak eMudhra keys. That logging finished rolling out on October 21. Over the following week Cloudflare recorded about 22,000 attempted TLS handshakes involving the weak keys. Two thirds of those attempts were requests for test sites such as emudhra.we-have-a-problem.com. Most of the remainder went to origins that appeared to have created certificates for themselves using the weak intermediate. Any handshake configured to verify the certificate was refused after Cloudflare patched.

Evidence of forged certificates and scope of exploitation

Cloudflare reports roughly 160 handshakes where the certificate Subject Alternative Names named domains unrelated to the Server Name Indication used in the connection. Some of those names were domains tied to consumer IoT devices. Several forged certificates were valid for more than two years, longer than a public CA would normally issue. Cloudflare observed a forged certificate dated October 20 at 18:19 UTC, less than an hour after a Mozilla bug report went public, showing that forgery activity began quickly.

However, Cloudflare says there is no evidence so far that the weak keys were used to intercept Cloudflare outbound connections. Many of the forged certificates looked like default server certificates and would have failed hostname verification, and in several cases the same certificate was presented from many of Cloudflare's locations, which suggests the certificates were served by the origins themselves rather than being placed on a particular network path. Cloudflare notes that targeted interception cannot be excluded, and they continue to look for indirect signals of compromise, but they have not seen those signals yet.

Who still accepts the compromised chain

Cloudflare used challenge pages to probe whether visitors still trust the compromised eMudhra chain. They sent probe connections from challenge pages to two endpoints, initially using an eMudhra-signed certificate on one endpoint and a normally signed certificate on the other as a control, and recorded whether client probes succeeded. With roughly 50 million probes over the week, Cloudflare found modern browsers were mostly patched, but bots and older browsers were not. Embedded browsers, such as Android WebView, lagged with 30 to 40 percent still accepting the compromised chain.

Cloudflare also observed traffic skew and bot-driven distortions in the probe data. A spike tied to traffic identifying as Chrome 150 to 154 on macOS altered acceptance rates in some graphs, and acceptance for Chrome 150 to 154 on Linux continued to decline, which is consistent with patching in that group. When broken down by large networks, Cloudflare found more than half of probes across many networks still accepted the compromised chain, though the company emphasizes that bot-heavy and changing traffic mixes are a big caveat.

Practical steps for small sites and teams

• Patch browsers and operating system TLS stacks promptly, especially developer machines on macOS, following available community guidance. Cloudflare recommends patching and mentions a crowdsourced set of instructions maintained by Dennis Jackson.
• Update embedded browser components, for example Android WebView, which lag behind desktop browsers in accepting the compromised chain.
• Check your servers and certificate chains for any certificates chaining to eMudhra intermediates, and replace any certificates signed by the compromised keys.
• Ensure clients and services verify Certificate Transparency logs where possible, because unpatched clients not enforcing Certificate Transparency could accept forged certificates.
• Monitor logs for unexpected certificates, SANs that do not match SNI, or certificates with unusually long validity.

What to watch and when to get help

Cloudflare cautions that patching progress has slowed after an initial burst, and that bots and legacy software remain a significant vector of continued acceptance. They also note unresolved questions about how the weak keys were generated, and that eMudhra has said it will exit the public CA business and has not published the key generation script the company cited.

If you run public-facing sites, or manage devices with embedded browsers, prioritize patching and inventorying certificates now. If you want help checking chains, scanning your infrastructure for certificates tied to the weak eMudhra intermediates, or applying fixes, get in touch with our team at Jones Web Designs via our contact page for a Formidable Masterminds developer consult: /contact.html.

For the full technical writeup and the raw reporting from the organization that tracked this, see the Cloudflare Blog post on the issue: Cloudflare: 4 real? Tracking exploitation and patching of eMudhra’s weak keys.