> ## 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

> Resolutions for common errors when integrating AppViewX with CryptoHub over the REST API and the Excrypt protocol bridge.

The Excrypt protocol bridge returns `200` for both success and protocol-level failure, so read `AO`, `AN`, and `BB` in the response body rather than relying on the HTTP status code. A response with `AO` set to `ERRO` is a failure.

## The bridge returns 403

**Cause:** The endpoint identity is not authorized for the Host API command in the `AO` field. Creating the AppViewX endpoint authorizes `RKPK` and `RKOP:request` automatically, so a `403` usually means the endpoint is missing or disabled, or was created from the wrong template.

**Fix:** Confirm the AppViewX service is deployed and its endpoint exists and is enabled, as described in [Prepare CryptoHub](/Integrations/CryptoHub/Certificate_management/AppViewX/Integration_steps/Prepare_CryptoHub). If the endpoint is absent or was created from a different template, re-create it from the AppViewX service so it carries the `RKPK` and `RKOP:request` authorization.

## The bridge returns 401

**Cause:** The request carried no valid session. Either the token was omitted, was malformed, or expired.

**Fix:** Confirm the `Authorization` header is spelled correctly and carries the current token. Re-authenticate against `/home/v1/login` and retry. Configure AppViewX to re-authenticate based on `tokenExpiration` rather than a fixed interval.

## `BB` says `USER NOT LOGGED IN`

**Cause:** The command reached the device without an authenticated Host API session.

**Fix:** This indicates the session used for the bridge call is not the session the command sees. Confirm the login succeeded and returned `fullyLoggedIn: true`, and that the same session is carried on the bridge call.

## `BB` says `INVALID KEY USAGE`

**Cause:** The `KU` value names a usage the key type does not support.

**Fix:** Send `KU` as `S` for asymmetric sign and verify, the usage a CSR-signing key needs. CryptoHub reads the leading usage character, so `SV` is also accepted as sign and verify. See [RKPK: Populate Generated Key Pair](/Host_API/Commands/RKPK_Populate_Generated_Key_Pair) for the full list of usage values.

## `BB` says `EXPONENT OUT OF RANGE`

**Cause:** The `RA` value is not a valid RSA exponent. This also occurs when `RA` is omitted, or when an ECC curve value is sent without setting `KT` to `2`.

**Fix:** Send `RA` as `10001`, the hexadecimal form of 65537. The value must be odd.

## `BB` says `MODULUS SIZE OUT OF RANGE`

**Cause:** The `RB` value is missing or is not a valid RSA modulus size.

**Fix:** Send a modulus size divisible by 8, such as `2048` or `4096`. Confirm the key group permits that size.

## `BB` says `INVALID MAJOR KEY`

**Cause:** The `MK` value does not name a recognized major key.

**Fix:** Send `MK` as `6` for the PMK, or `1` for the MFK. Confirm the selected major key is loaded on the device.

## `BB` says `Invalid hash type.`

**Cause:** The hash selector is outside the supported range. `RKOP` accepts `1` through `7` only, and `0` is not valid.

**Fix:** Send `4` for SHA-256, or omit the token to accept the SHA-256 default.

## The CSR came back signed with an unexpected hash

**Cause:** The numeric hash encoding is not uniform across Host API commands. On `RKOP`, `2` is MD5, `3` is RIPEMD160, and `4` is SHA-256. A workflow that sends `2` expecting SHA-256 produces an MD5-signed request.

**Fix:** Send `4` for SHA-256, then confirm the result with `openssl req -inform DER -in request.der -text -noout` and check the `signatureAlgorithm` field. Read the hash table on the reference page for the specific command you send rather than reusing a value from another command.

## The key does not appear in the key group

**Cause:** The generation request sent `FC:0`, which returns a temporary result that is not stored. An RKPK key pair persists by default, so an explicit `FC:0` is the usual cause.

**Fix:** Omit `FC`, or send `FC:1` to persist explicitly. Confirm the response carries an `ID` token, which is returned when the key pair is persisted.

## The key exists but the symmetric key commands cannot find it

**Cause:** An RKPK-generated key pair is a PKI key pair, and the symmetric key commands do not operate on it.

**Fix:** Use [PGKE: Paginated Keys](/Host_API/Commands/PGKE_Paginated_Keys) to list it and [RKDP: Delete PKI Key Pair](/Host_API/Commands/RKDP_Delete_PKI_Key_Pair) to remove it.

## `BB` says `ERROR RETRIEVING CERTIFICATE`

**Cause:** The selector in the CSR command does not match an object on the device. In the 7.0.3.x key-name flow, `NA` does not match a persisted key pair.

**Fix:** Confirm `NA` matches the key name recorded when you ran `RKPK`, and that the key pair persisted. List keys with [PGKE: Paginated Keys](/Host_API/Commands/PGKE_Paginated_Keys) to verify.

## `BB` says `Cannot sign request without private key.`

**Cause:** The object the CSR command selected has no private key to sign with.

**Fix:** Confirm `NA` names the RKPK-generated key pair, which holds its private key in the HSM. Confirm the key persisted and appears in [PGKE: Paginated Keys](/Host_API/Commands/PGKE_Paginated_Keys).

## The issued certificate has no subject alternative names

**Cause:** CryptoHub does not carry SANs in the CSR, and the certificate authority took SANs only from the CSR extension rather than from the request submission.

**Fix:** Configure the certificate authority to accept SAN values supplied with the request, or configure the certificate template or profile to populate them. Reissue after correcting the configuration.

## The CSR call returns a selector error

On CryptoHub 7.0.3.x, `RKOP` with `OP=request` builds the CSR directly from an RKPK-generated key pair selected by `NA`, together with the subject-override tokens. The [RKOP: Request](/Host_API/Commands/RKOP_Manage_Private_Key_Certificate_Links/RKOP_Request) reference describes the certificate-selector form (`CA` plus `RT`, `AL`, or `ID`) that later firmware uses.

If the call returns a selector or private key error, confirm you are sending the key-name form for 7.0.3.x: `NA` set to the RKPK key name, plus the subject tokens. Do not send a `CA` container selector with `NA`.

## Related

* [Excrypt protocol bridge](/REST_API/Docs/Service_integrations/Excrypt_protocol_bridge)
* [Login](/REST_API/Docs/Identity_and_access/Login)
* [Send authenticated excrypt commands](/CryptoHub/7.3.0.x/Administrator_guide/HSM_management/Managing_HSMs/Send_authenticated_excrypt_commands)
* [RKPK: Populate Generated Key Pair](/Host_API/Commands/RKPK_Populate_Generated_Key_Pair)
* [RKOP: Request](/Host_API/Commands/RKOP_Manage_Private_Key_Certificate_Links/RKOP_Request)
* [RKSR: Generate Certificate Signing Request](/Host_API/Commands/RKSR_Generate_Certificate_Signing_Request)
* [Error Handling](/Host_API/Commands/Error_Handling)