> ## Documentation Index > Fetch the complete documentation index at: https://docs.futurex.com/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting > Diagnose and resolve the common failure modes of the Java Jarsigner and CryptoHub integration, including the FIPS-mode verification limitation. 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 expandable lines wrap title="Shell" theme={null} cat /proc/sys/crypto/fips_enabled ``` Otherwise, the `pkcs11.cfg` file that the provider line points at is missing its `name` attribute. The JVM builds the provider name as `SunPKCS11-`, 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](/Drivers_and_libraries/Java_PKCS11_developer_guide/Installation/Install_Java_Cryptography_Environment/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 ` NO ` 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](/Drivers_and_libraries/Java_PKCS11_developer_guide/Installation/Install_Java_Cryptography_Environment/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: | Family | Permissions | | ------ | ----------------------------------------------------------- | | Keys | `Change Metadata`, `Export`, `Import`, `Key Stores`, `Move` | | Pki | `Generate`, `Import`, `Change Metadata` | 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: ```xml expandable lines wrap title="fxpkcs11.cfg" theme={null} DEBUG YES ``` ## `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 expandable lines wrap title="Shell" theme={null} jarsigner -J-Dcom.redhat.fips=false -verify demo_signed.jar -verbose -certs ``` * 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 expandable lines wrap title="Shell" theme={null} export FXPKCS11_CFG=/etc/fxpkcs11.cfg ``` 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 `-:`, where `` 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](/Integrations/CryptoHub/Code_signing/Java_Jarsigner/Jarsigner_command_examples).