According to this article : https://blogs.oracle.com/java-platform-group/planning-safe-removal-of-under-used-endorsed-extension-directories
the jre/lib/ext removed in Java 9.
My problem is that I am using Jarsigner which in previous Java versions found my provider jar in the jre/lib/ext folder.
jarsigner -tsa timestamp.digicert.com -verbose -keystore NONE -storetype PKCS11
-storepass null -providername <MY_PROVIDER_NAME> <JAR_FILE> <CERTIFICATE_NAME>
How can I solve it?
The changes to the installed JDK/JRE image brings along runtime images which consists of directories including -
conf — contains .properties, .policy, and other kinds of files intended to be edited by developers, deployers, and end users. These files were formerly found in the lib directory or its subdirectories.
The java.security file within JDK9 (located under .../Home/conf/security) lists out the SunPKCS11 provider amongst the list of default providers
security.provider.13=SunPKCS11
#SunPKCS11 Configuration under the reference guide details out how to add provider which is present in the jdk.crypto.cryptoki module of the JDK.
So, ideally there shouldn't be a need to configure path to the sunpkcs11 provider in Java9 as well.
To add and example of how providers are bundled into modules, to it from the JEP 220: Modular Run-Time Images
Security-policy files and other uses of the CodeSource API can use jrt URLs to name specific modules for the purpose of granting permissions. The elliptic-curve cryptography provider, e.g., can now be identified by the jrt URL
jrt:/jdk.crypto.ecOther modules that are currently granted all permissions but do not actually require them can trivially be de-privileged, i.e., given precisely the permissions they require.