Tests Show Re-Encoded Certificates Can Bypass Java Fingerprint Blocking
Summary
Sonatype tests found that Java rejected listed eMudhra intermediate certificate encodings but accepted re-encoded versions with different SHA-256 fingerprints in the tested JDK and trust-store configurations.
Key points
- Sonatype tested ECDSA- and RSA-signed intermediate certificates associated with the eMudhra incident.
- In the ECDSA test, changing the signature value from s to n − s produced another valid signature representation.
- In the RSA test, removing the NULL parameter from the outer signature algorithm identifier left the certificate-data signature unchanged.
- Java rejected the original chains when their intermediate fingerprints were listed in blocked.certs, but trusted the re-encoded chains with different fingerprints.
- Removing the relevant roots from the copied trust store caused both chains to be rejected in the tests.
- The results apply only to the JDK versions and trust-store configurations tested; Sonatype advises verifying protections in deployed runtimes and testing trust-store changes for TLS impact.
Article Details
- Attack Vectors
- In tested Java configurations, an ECDSA-signed intermediate certificate was re-encoded by changing the signature value from s to n − s, producing a different SHA-256 fingerprint while the chain still validated despite the original fingerprint being listed in blocked.certs.
- In tested Java configurations, an RSA-signed intermediate certificate was re-encoded by removing the NULL parameter from the outer signature algorithm identifier. Its fingerprint changed while the certificate chain still validated despite the original fingerprint being listed in blocked.certs.
- Defensive Notes
- Verify certificate mitigations in the Java runtimes and trust stores actually deployed; the reported results apply only to the JDK versions and trust-store configurations tested.
- Removing the relevant roots from the tested trust stores caused both original and re-encoded chains to be rejected, but may interrupt legitimate TLS connections.
- Before changing a trust store, identify dependent services and test their certificate chains; monitor for TLS failures after deployment.
- Follow current vendor guidance and document any exceptions.