Search code examples
javasecuritysignaturepolicyjava-14

ECDSA Algorithms not available in Java with jlink

I'm writing a Java 14 application that should verify some signatures with algorithms such as SHA256withECDSA, SHA384withECDSA and SHA512withECDSA, but I'm experiencing a particular side-effect of jlink:

  • when running the application with the Standard JDK/JRE 14 runtime, the algorithms are showing up (SunEC is loaded successfully)
  • when running the application with an optimized version of the JRE runtime, using jlink AND including the jdk.crypto.ec module, SunEC isn't loaded at all and the algorithms aren't available

I'm aware of this Ticket in the OpenJDK bug tracker, but I cannot understand why there's a different behaviour in the optimized jlink version.

In the runtime folder generated by jlink, there's also the libsunec.so.

I'm printing out the available algorithms with this SO snippet and I obtain the following output:

MD2withRSA
MD5andSHA1withRSA
MD5withRSA
NONEwithDSA
NONEwithDSAinP1363Format
RSASSA-PSS
SHA1withDSA
SHA1withDSAinP1363Format
SHA1withRSA
SHA224withDSA
SHA224withDSAinP1363Format
SHA224withRSA
SHA256withDSA
SHA256withDSAinP1363Format
SHA256withRSA
SHA384withRSA
SHA512/224withRSA
SHA512/256withRSA
SHA512withRSA

For same and related reasons, the verification of signed Jars with policy files doesn't work.

Could anyone explain/point me what should I look for?

EDIT: the jlink runtime is built with the following arguments:

jlink --strip-debug \
      --strip-native-commands \
      --bind-services \
      --no-header-files \
      --no-man-pages \
      --compress=2 \
      --module-path ${JAVA_HOME}/jmods \
      --add-modules java.desktop,java.smartcardio,java.management,java.sql,java.logging,java.net.http,java.xml.crypto,jdk.crypto.ec \
      --output jlink-runtime
Solution

  • This is an official bug of the JDK now.

    There is currently no support for signed JARs on the application module path that are signed with EC certs. The reason is that module path is scan early during VM startup, long before code outside of java.base can execute. JDK-8215932 tracks the same issue.