Certificate Transparency explained: why eMudhra's weak keys only fool clients that skip CT

In short

Certificate Transparency (CT) is a public, append-only record of the TLS certificates that certificate authorities (CAs) issue. It does not stop a bad certificate from being created, but it makes one visible, and a browser that insists on proof of logging will reject a forged certificate that was never logged. That is why the weak eMudhra keys disclosed in October 2026 are dangerous mainly to clients that do not enforce CT.

Why this matters this week

On 19 October 2026 Cloudflare learned that private keys behind eight eMudhra intermediate certificates were compromised. A follow-up post on 30 October says the keys were absurdly weak: one was the number 4, and the others were 56, 66, 115, 155, 156, 230 and 237. Because such keys can be recovered from public certificates, anyone could forge certificates that clients not enforcing Certificate Transparency would accept, according to Cloudflare. We covered the first disclosure, the Windows update that removes the certificates and the Java fixes. This guide explains the mechanism that sits behind the phrase "clients not enforcing CT".

Step 1: what a certificate authority does

When you open a site over HTTPS, the server presents a certificate that says "this public key belongs to example.com". Your device trusts that statement because a CA signed it, and the CA's own certificate chains up to a root that ships in the operating system or browser trust store. Between the root and the site there are usually one or more intermediate certificates, which is what eMudhra's eight compromised certificates were.

Whoever holds the private key of a trusted intermediate can sign a certificate for any domain, and the chain will look valid. That is why a leaked or guessable intermediate key is so serious: the attacker does not need to break the site, only to sit between the visitor and the server and present a forged certificate.

Step 2: the weakness CT addresses

For years the system had a blind spot. If a CA was hacked, or issued a certificate by mistake, nobody except the victim of the resulting attack might ever know. Certificate Transparency, specified in RFC 9162 (version 2.0, which obsoletes RFC 6962), adds public logs. The RFC describes it as a way of publicly logging TLS server certificates as they are issued or observed, so that anyone can audit CA activity and spot suspect certificates.

The same document is candid about the limit: the logs "do not themselves prevent misissuance". What they do is make misissuance detectable.

Step 3: how the logs work

• Append-only logs. Anyone can submit a certificate chain to a log, as long as it ends in a trust anchor the log accepts. The log only ever adds entries.
• Signed certificate timestamps (SCTs). When a log accepts a chain, it returns a signed timestamp, a receipt. A TLS client can treat an SCT as evidence the certificate was submitted to a log, and a client can require one.
• Merkle trees. The log uses a Merkle tree so that outsiders can verify efficiently that a newer log state extends an older one. This helps detect a log that misbehaves, for example by handing out an SCT for a certificate it never recorded.
• Monitors. A domain owner can fetch new log entries regularly and check for certificates for their domains that they did not request. That is how a forged or misissued certificate gets noticed.
• Inclusion proofs. Anyone holding an SCT can later ask the log for a proof that the certificate is really included. If the log cannot provide it, that is evidence the log is not operating correctly. These checks are asynchronous so they do not slow down connections.

The RFC also states a boundary: a log can show different views to different clients, so each log is treated as a trusted third party, and stronger defences are outside its scope.

Step 4: why weak keys still matter even with CT

Put the pieces together. An attacker who can compute the eMudhra intermediate key can mint a certificate for, say, your bank's domain. If your client demands an SCT, the forged certificate must be in a public log to be accepted, and then a monitor can see it. If the attacker skips logging, a CT-enforcing client rejects it. If your client does not enforce CT, which is the case Cloudflare highlights, nothing stops it from accepting the forgery silently.

Cloudflare's 30 October data shows who is in that second group. Over about a week it sent 50 million probes through its challenge pages. It warns the results are skewed by unconfirmed bot traffic and that only clients that run JavaScript send probes. Modern browsers are mostly patched, but bots, old browsers and embedded browsers lag: Android WebView still accepted the weak chain in 30 to 40% of probes, and across large networks more than half of probes still accepted the compromised chain, with little change after the first weekend. Probes are a sample, not a census of devices.

Step 5: what Cloudflare saw in practice

Cloudflare logged roughly 22,000 handshakes that used the weak keys over about a week. About two thirds were tests against a test site, and nearly all the rest were origin servers using the weak intermediate for their own certificates. Verifying clients refused every one. About 160 handshakes presented certificates naming other organisations' domains, some tied to consumer IoT devices; Cloudflare says these looked like servers' default certificates, not interception attempts. It found no evidence the keys were used to intercept its connections, and adds that targeted interception cannot be ruled out. The company also says all high-priority systems are patched, with a few low-impact tickets remaining.

What to do

• Update software that carries its own trust store. Cloudflare's earlier advice covers its WARP and 1.1.1.1 clients and cloudflared; Cloudflare points to Dennis Jackson's crowdsourced site, emudhra.we-have-a-problem.com, for patching instructions by platform. Our Java and Windows articles above cover those.
• Review origin certificates. If your origin server uses a certificate chained to a distrusted eMudhra intermediate, replace it.
• Do not turn off certificate verification to clear an error: that removes the protection the fix relies on.
• Check dependency trees, not just SDK versions, and test through your application's real TLS path, as Cloudflare advises.

What it means

The episode shows CT working as designed and also its limit. The log makes forged certificates detectable, but only where a client demands proof. The weakest link is old and embedded software that never enforced CT or never received the trust-store update.

What we don't know yet

• eMudhra says it is exiting the public CA business and blames a mistake in a key generation script, but, as Cloudflare reports, it has not shared the script, so the cause is unverified.
• No one has published a count of devices still accepting the weak chain; Cloudflare's probe numbers are a skewed sample.
• Cloudflare cannot rule out targeted interception elsewhere.

What to watch next

Watch for trust-store updates reaching Android WebView and embedded devices, for eMudhra's account of the key generation error, and for the faster trust-store update systems Cloudflare says it supports, such as upki, which combine revocation with CT information.

Sources

• Cloudflare: eMudhra weak keys, tracking exploitation and patching (30 October 2026)
• Cloudflare: eMudhra certificate compromise (October 2026)
• RFC 9162: Certificate Transparency Version 2.0