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 theAO 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. 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 theAuthorization 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 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. OnRKOP, 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 sentFC: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 to list it and 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 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.
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 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.