Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • October 18, 2016

Oracle JRE will no longer trust MD5-signed code by default

Guest Author

Update notice

When this blog post was originally posted the change was scheduled to occur with the January 2017 Critical Patch Update. In response to requests for additional time to prepare for this change Oracle now plans to deliver this change with the April 2017 Critical Patch Update. The post has been updated accordingly.


Beginning with the April 2017 Critical Patch Update, JAR files signed using MD5 will no longer be considered as signed by the Oracle JRE. Affected MD5-signed JAR files will no longer be considered trusted and as a result will not be able to run by default, such as in the case of Java applets, or Java Web Start applications.

This change in the JRE behavior is required because MD5 is no longer considered secure and is widely considered unsuitable for security use.  In fact, the MD5 with RSA algorithm stopped being the default JAR signing option with Java SE 6 released back in 2006.  It is critical that weak hashing algorithms (such as MD5) be deprecated when they are known to be weak so as to maintain the trust in the verification mechanism they provide.  

This change affecting MD5-signed JARS will be enabled by default no sooner than with Oracle Java SE 8u131 which will be released with the April 2017 Critical Patch Update, as well as in the corresponding releases of Oracle Java SE 7, Oracle Java SE 6 and Oracle JRockit R28, which will be available to qualified customers through My Oracle Support.

In order to prepare for this upcoming change, developers need to verify that their JAR files have not been signed using MD5.  You can do this with your own JARs by verifying your build process signs JARs using Java 6 or later without having deliberately chosen MD5.  If you are using JARS you did not sign or build yourself, you need to contact your vendor for more information.  If it can no longer be established if a JAR you are using has been signed with MD5, the recommended practice is to re-sign affected JAR files using a more modern algorithm.  Be sure to remove any existing MD5 signatures first before re-signing using the zip utility as follows:

zip -d test.jar 'META-INF/*.SF'

More technical information can be found in the October 2016 Critical Patch Update Release Notes for Java SE.

Oracle has already informed a number of software vendors, including source licensees, of the upcoming changes.  Users concerned about the effect of this change on third party applications should contact their respective vendor.

Cryptography is a dynamic field.  In order to keep users and developers informed about upcoming changes in this area, Oracle has recently published a new web page at java.com/cryptoroadmap.  This page provides information about upcoming cryptographic changes in Oracle JRE and Oracle JDK, and related technical instructions.

Join the discussion

Comments ( 4 )
  • guest Friday, October 21, 2016

    Is it possible to validate with "jarsigner -verify" or "keytool -printcert" or any other JDK-shipped tools what algorithm is used in an existing JAR file? I have a few JARs that have been signed with a custom tool (not jarsigner) and I have no idea what algorithm that tool uses... (but I assume it is fine since it supports timestamping and IIRC timestamping was added after the change from MD5 to SHA1)

  • Erik Costlow Friday, October 21, 2016

    Yes, I will post about that along with some other things later.

    Use the recent 8u111+ and add a flag:

    jarsigner -verify -J-Djava.security.debug=jar

    In January (when the change above happens), this should move into the normal -verbose option.

  • Paul Bransford Monday, October 31, 2016

    Will it be possible to disable this, or perhaps allow specific signers? I'm concerned about defunct vendors who will not be around to update their jars themselves, and where we may not be able to modify the jar ourselves (eg to strip and resign) - such as embedded devices.

  • Erik Costlow Monday, October 31, 2016

    Yes to disabling/changing, no to specific signers since the issue is with the signing algorithm.

    The instructions to revert the change are at the crypto roadmap under the MD5 change for January and involve changing the jdk.jar.disabledAlgorithms property. I wouldn't recommend that approach though.

    Assuming you're running the signed apps as Web Start or Applets, you should have an easier time whitelisting them.

    Within an organization, use a Deployment Rule Set and create a run rule for the app's location. This is "does a rule exist for this application" on http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_flow.html

    For unmanaged individuals, they can use their own Exception Site List which may not work as well due to its location on the flowchart.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.