The Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass
3 minute read time
TL;DR
-
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. Each re-encoded certificate had a different SHA-256 fingerprint.
-
The results apply to the JDK versions and trust-store configurations tested. Follow current vendor guidance and verify the protections in the runtimes and trust stores you deploy.
A certificate blocklist can reject a known-bad certificate and still miss another encoding of it.
We saw this while examining Java's response to the eMudhra certificate incident. The mitigation uses SHA-256 fingerprints to identify compromised intermediate certificates. But a certificate’s fingerprint is calculated from its exact encoded bytes.
During an AI-assisted review, Sonatype Research Labs asked Opus 5.5 whether Java's exact-fingerprint blocking could be bypassed. The AI model flagged that exact-byte matching might leave room for equivalent certificate encodings.
We confirmed the behavior for both ECDSA and RSA certificates: re-encoded intermediates had different SHA-256 fingerprints, yet still validated in our Java trust-store tests. This points to a limit in exact-fingerprint blocking: it can identify the certificate bytes it knows about without necessarily covering every equivalent encoding.
Here, we’ll explain how the re-encoding works, what the tests show, and what teams should check before relying on a certificate blocklist as their only mitigation.
How It Started: eMudhra Certificates Compromised
Several eMudhra intermediate certificate authority keys were compromised on October 20, 2026, allowing anyone who obtained a key to create certificates that could be trusted as part of a chain to a trusted root. Browser and platform vendors responded with blocks and trust-store changes.
This also prompted a Java mitigation: add the affected intermediates to blocked.certs. Our research began with a narrower question: does that fingerprint-based block reject every valid encoding of those certificates?
How Exact-Fingerprint Blocking Works
A certificate is a structured document: it contains information such as the subject, public key, issuer, validity period, and a digital signature. In Java, blocked.certs identifies certificates by their SHA-256 fingerprints. The fingerprint is calculated from the certificate's encoded bytes, so even a small change to those bytes produces a different fingerprint.
This makes fingerprint blocking precise, but the match depends on the exact encoding in the blocklist. If a certificate can be re-encoded and still pass signature validation, the new encoding may have a different fingerprint and may not match the listed entry. To test whether an alternate encoding could still validate in practice, we examined two signature formats: ECDSA and RSA.
Changing the Encoding Changes the Result
We tested two certificate chains from the eMudhra incident advisory: one with an ECDSA-signed intermediate and one with an RSA-signed intermediate. For each, the reproduction added the original intermediate's SHA-256 fingerprint to a copy of a JDK's blocked.certs file, changed the intermediate's encoding without its private key, then checked whether the chain still validated.
The two encoding changes were:
-
ECDSA: The script changes the signature value from s to n − s, another valid representation of the signature.
-
RSA: It removes the NULL parameter from the outer signature algorithm identifier. The signature over the certificate data remains unchanged.
Both tests produced the same result: Java rejected the original chain whose intermediate fingerprint was listed, but trusted the chain with the re-encoded intermediate, whose fingerprint was different. After the relevant roots were removed from the copied JDK’s trust store, both chains were rejected.
Verify the Mitigation in Your Runtime
Teams should verify certificate mitigations in the Java runtimes and trust stores they deploy. Removing the relevant roots rejected both chains in our tests, but it can also interrupt legitimate TLS connections. Before changing a trust store, identify dependent services, test their certificate chains, and monitor for TLS failures after deployment.
Follow current vendor guidance and document any exceptions. These results cover only the JDK versions and trust-store configurations we examined, so validate the controls separately for other runtimes and TLS paths in your environment.
Written by Sonatype Research Team
Sonatype's Research Team is focused on bringing real-time, in-depth intelligence and actionable information about open source and third party vulnerabilities to Sonatype customers.
Explore All Posts by Sonatype Research TeamTags
