---
id: "TECH-202610-java-s-blocked-certs-fix-for-the-compromised-emudhra-cas-can"
kind: "technique"
aliases: []
title: "Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "Java", "affected": "unknown (JDK versions using blocked.certs fingerprint mitigation for eMudhra)", "ecosystem": "maven"}, {"name": "OpenJDK", "affected": "unknown"}]
ecosystems: []
tags: ["early-warning", "emudhra", "java", "technique", "tls"]
not_affected_if: []
published_at: null
first_seen_at: "2026-10-26T23:27:13+00:00"
updated_at: "2026-10-26T23:27:13+00:00"
sources: [{"source": "analyst", "url": null, "first_seen_at": "2026-10-26T23:27:13+00:00"}]
---

# Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate

Several eMudhra intermediate CA keys were compromised on 2026-10-20. Java's mitigation adds those intermediates' SHA-256 fingerprints to blocked.certs. Sonatype Research (2026-10-21) showed that an intermediate can be re-encoded without its private key (ECDSA: swap signature s for n-s; RSA: drop the NULL parameter from the outer signature algorithm). The new encoding has a different fingerprint, is not matched by blocked.certs, and still validates in the JDK configurations they tested. So a Java service or client that relies only on blocked.certs may still trust TLS chains through the compromised eMudhra intermediates if an attacker can intercept its traffic. The JDK versions tested are not named. No exploitation reported so far. The same exact-fingerprint weakness may apply to other runtimes or tools that block by fingerprint (unverified).

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- maven:Java affected unknown (JDK versions using blocked.certs fingerprint mitigation for eMudhra) fixed ?
- :OpenJDK affected unknown fixed ?

## How to check

Check whether your Java runtimes (JDK/JRE, including bundled JREs in apps and containers) still trust the eMudhra roots in their cacerts trust store (keytool -list -cacerts, look for eMudhra entries) and whether your only eMudhra mitigation is the blocked.certs fingerprint entry. If the roots are still trusted, you are exposed to the re-encoded bypass. Affected JDK versions: unknown.

## Fix

Do not rely on the blocked.certs fingerprint entries alone. Where you can, remove or distrust the relevant eMudhra roots from the Java trust stores you ship (cacerts or a custom truststore). First find the services that legitimately depend on eMudhra chains and test them, then watch for TLS failures after the change. Follow Oracle/OpenJDK vendor guidance as it updates, and check the same thing in other runtimes that ship their own cert stores.

## Timeline

- 2026-10-26T23:27:13+00:00 analyst

## Documents

- [describes] The Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass https://news.ycombinator.com/item?id=50252311
- [describes] The Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass https://www.sonatype.com/blog/the-limits-of-fingerprint-blocklists-a-reproducible-java-certificate-bypass
- [describes] @feross: eMudhra's 8-bit CA keys and the Brotli flaw hit in the same week. Updating Node  https://x.com/feross/status/2114854876874207512

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_