Skip to main content
Each entry below names the error string you see, then the cause and the fix.

​
java.security.NoSuchProviderException: no such provider: SunPKCS11-Futurex

Symptom: keytool or jarsigner reports that the provider does not exist, even though you added a security.provider.N line to java.security and restarted. Cause: One of two things. On a Linux system running in FIPS mode, the JVM ignores the security.provider.* list entirely. During startup the system configurator deletes every security.provider.* entry and rebuilds the provider list from fips.provider.* instead, so the Futurex entry never survives to your application. Confirm FIPS mode with the following command, where a result of 1 means it is on:
Shell
Otherwise, the pkcs11.cfg file that the provider line points at is missing its name attribute. The JVM builds the provider name as SunPKCS11-<name>, so without that attribute there is no SunPKCS11-Futurex to find. Solution: Confirm the pkcs11.cfg file contains a name = Futurex line. Then, if FIPS mode is on, register the provider as a fips.provider.N entry instead, as described in Configure the provider in FIPS mode.
Append the Futurex provider at the next free fips.provider.N index. Do not repoint fips.provider.1 at your Futurex pkcs11.cfg. That line is the JVM’s only software digest source in FIPS mode, and replacing it breaks SHA-384 for every application on the JDK.

​
java.security.ProviderException: FIPS: error during the Token login required for the MessageDigest service

Symptom: A digest or signing operation fails with this message on a FIPS-enabled Linux host. The fxpkcs11.log shows C_FX_LoginWithUser: CKR_ARGUMENT_BAD. Cause: FIPS-mode JDK builds on Red Hat Enterprise Linux attempt to log in automatically to any registered SunPKCS11 token, using the PIN from the fips.nssdb.pin security property. Its stock value is the empty string, which is correct for the local NSS database but not for a network HSM. The Futurex PKCS #11 module correctly rejects the empty PIN, and the Java Cryptography Architecture does not fall through to the next provider after a ProviderException, because one provider’s failure aborts the whole algorithm lookup. Solution: Prevent the implicit login from reaching the Futurex token, using either approach:
  • Set <REQUIRE-LOGIN-FLAG> NO </REQUIRE-LOGIN-FLAG> in fxpkcs11.cfg. SunPKCS11 then reads the token’s CK_TOKEN_INFO flags, sees that login is not required, and skips the attempt. Your application still authenticates normally when it opens a session.
  • Add disabledMechanisms = { CKM_SHA256 CKM_SHA384 CKM_SHA512 } to pkcs11.cfg, so digest lookups never reach the Futurex provider in the first place.
Both are described in Configure the provider in FIPS mode.

​
Signing fails with an insufficient-permissions error

Symptom: keytool -genkeypair or jarsigner fails against the CryptoHub, and the appliance logs report insufficient permissions. Client-side, the failure may surface only as a generic CKR_* code such as CKR_FUNCTION_FAILED or CKR_TEMPLATE_INCONSISTENT that names no permission. Cause: The identity that the client endpoint authenticates as does not hold the permissions the code-signing workflow needs. Because PKCS #11 return codes carry no permission detail, a missing grant looks like a configuration or template error. Solution: Confirm the endpoint’s role holds the permission set the Java Jarsigner service template applies: Review them in Identity and Access > Roles. Keys:Key Stores and Keys:Move are required for the SunPKCS11 key store binding, and the Pki permissions cover creating the code-signing certificate object from the generated key pair. Signing itself is governed by the Sign and Verify asymmetric usages on the key, not by a separate permission. To see what the appliance reported rather than the code the client library returned, enable traffic logging in fxpkcs11.cfg and rerun:
fxpkcs11.cfg

​
java.security.NoSuchAlgorithmException: SHA-384 MessageDigest not available on jarsigner -verify

Symptom: Signing succeeds and reports jar signed, but jarsigner -verify on the same JAR fails with this message and treats the JAR as unsigned. The surrounding output may include processEntry caught:, which is the verifier swallowing the exception. Cause: This is a limitation of the FIPS-mode JDK, not a defect in the Futurex PKCS #11 module and not a configuration error. When the JDK verifies a JAR signature, it narrows the live provider list, for the duration of the verification, to a hardcoded set of four providers: SUN, SunRsaSign, SunEC, and SunJCE. It then requests the manifest digest algorithm with no provider argument. In FIPS mode the SUN provider registers no MessageDigest implementations at all, so none of those four can supply SHA-384, and the lookup fails.
The message wording identifies which lookup failed. SHA-384 MessageDigest not available comes from a lookup with no provider argument inside the restricted verification window. A message of the form no such algorithm: SHA-384 for provider SUN comes from an ordinary provider-specific lookup and points to a different problem.
Solution: No Futurex-side setting resolves this, because SunPKCS11 is structurally excluded from the verification window. In particular:
  • Registering the Futurex provider at a different fips.provider.N index does not help. Its position is irrelevant when the whole provider class is excluded.
  • Adding a third-party FIPS provider such as BCFIPS does not help either, because it is also outside the hardcoded four.
  • -digestalg and -sigalg are sign-time flags only. JDK 21 defaults -digestalg to SHA-384 and, for a 2048-bit RSA key, -sigalg to SHA384withRSA, and the resulting .SF file records SHA-384-Digest-Manifest. Re-signing with different flags changes which digest verification requires but not that it requires one, so it cannot avoid the failure.
Use one of the following workarounds. Signing in FIPS mode continues to work in every case:
  • Verify with FIPS mode disabled for that JVM only:
    Shell
  • Verify on a host, container, or JVM that is not running in FIPS mode.
Because the limitation is in the platform rather than in the Futurex integration, direct any request to change the behavior to Red Hat support. Red Hat documents the identical failure with no Futurex component involved in KB solution 7106529 (“SHA-256 MessageDigest not available in FIPS Mode”), which requires a Red Hat subscription to view.

​
C_GetSlotList: 0 slots found

Symptom: The fxpkcs11.log reports zero slots, and keytool cannot see the token. Cause: The Futurex PKCS #11 module cannot locate its own configuration file, fxpkcs11.cfg. This is separate from the SunPKCS11 provider configuration file, pkcs11.cfg, and passing pkcs11.cfg with -providerArg does not supply it. Solution: Export FXPKCS11_CFG in the shell that runs keytool or jarsigner, pointing at your fxpkcs11.cfg:
Shell
On Windows, set it machine-wide from an elevated Command Prompt with setx FXPKCS11_CFG "C:\Program Files\Futurex\fxpkcs11\fxpkcs11.cfg" /M, then open a new Command Prompt, because new environment variables reach new processes only. Also confirm the file is readable and that the module can write its log file.

​
jarsigner cannot find the alias

Symptom: jarsigner reports that the alias does not exist, even though keytool -list shows the key. Cause: The CryptoHub assigns the on-token key its own alias in the form <alias>-<id>:<alias>, where <id> is generated per key. That generated alias, not the short -alias value you passed to keytool -genkeypair, is what jarsigner must reference. Solution: Copy the exact alias from the keytool -list output and pass it as the final argument to jarsigner, as shown in Jarsigner command examples.