Java fingerprint blocklist misses re-encoded eMudhra certificates
Original title: The Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass
Re-encoded ECDSA and RSA intermediates still validated in tested JDKs after blocked.certs rejected the original encodings.
Sonatype Research Labs found that Java's blocked.certs list rejected listed encodings of compromised eMudhra intermediate certificates but accepted re-encoded copies with different SHA-256 fingerprints. Tests changed an ECDSA signature from s to n−s and removed an RSA NULL parameter without the private key. Both re-encoded chains still validated until the relevant roots were removed from the copied trust store. The result applies only to the JDK versions and trust stores tested.
Unconfirmed: Sonatype's results cover only the JDK versions and trust-store configurations it tested.
- eMudhra intermediate CA keys were compromised on October 20, 2026.
- blocked.certs matches SHA-256 fingerprints of exact certificate bytes.
- Removing the relevant roots rejected both original and re-encoded chains.
- Root removal can also interrupt legitimate TLS connections.
Impact: Re-encoded compromised intermediates can still validate in Java
| Product | Affected |
|---|---|
| Java JDK | — |
- 1.Verify blocked.certs behavior in the JDK runtimes and trust stores you deploy.
- 2.Test dependent services before removing the relevant roots.
From the original article
3 min read at sonatype.com
Sonatype's tests found that Java's blocked. certs rejected the listed certificate encodings but accepted re-encoded versions that still validated in the tested configurations. We reproduced the behavior with ECDSA- and RSA-signed intermediates associated with the eMudhra incident.
By sonatype.com via hanno · sonatype.com
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.