Generate a key pair and CSR in CryptoHub

AppViewX generates the key pair and the certificate signing request (CSR) inside CryptoHub by sending Host API commands through the Excrypt protocol bridge. The private key is created in the HSM and never leaves it.

Understand the bridge

Both operations post to /home/v1/excrypt. Each call submits one Host API command as a JSON body, where the four-character AO token names the command and the remaining tokens become additional key-value pairs. The endpoint returns 200 for both success and protocol-level failure, so inspect the body rather than the status code:

On success, AO echoes the command name and AN is Y.
On failure, AO is the literal ERRO, AM carries a numeric error code, AN names the offending field, and BB carries the error description.

For the full envelope, see Excrypt protocol bridge.

Token-level data types follow the Host API command documentation rather than a REST schema. When a value does not behave as expected, check the reference page for that specific command.

Generate the RSA key pair

Send RKPK to generate the key pair and persist it into the key group.

Request

{
  "AO": "RKPK",
  "KT": "1",
  "RA": "10001",
  "RB": "2048",
  "MK": "6",
  "KU": "S",
  "NA": "<key name>",
  "FC": "1",
  "KG": "<key group name>"
}

The tokens carry the following meaning. For the complete definitions, see RKPK: Populate Generated Key Pair.

Token	Value	Purpose
`KT`	`1`	RSA key type. This is also the default when `KT` is omitted.
`RA`	`10001`	RSA public exponent, 65537 in hexadecimal. Must be odd.
`RB`	`2048`	RSA modulus size in bits. Must be divisible by 8.
`MK`	`6`	Wrap the returned private key material under the PMK.
`KU`	`S`	Key usage: asymmetric sign and verify.
`NA`	Key name	Name to associate with the persisted key.
`FC`	`1`	Persist the key rather than returning a temporary result.
`KG`	Key group name	The key group that receives the key.

KU sets the key usage. S is asymmetric sign and verify, the usage a CSR-signing key needs. CryptoHub reads the leading usage character, so a value such as SV is also accepted as sign and verify.

An RKPK-generated key pair persists by default. This example sends FC:1 to persist it explicitly. Only an explicit FC:0 returns a temporary result that is not stored in the key group, which would leave the CSR step with no key to reference.

Give each key a unique name so concurrent enrollments do not collide. A common approach is to combine the requested common name with a timestamp, for example www.example.com_20260729_143000.

A successful response echoes the command with AN set to Y, returns the wrapped private key in RC, the public key in SD, a supplemental payload in DS, an operation reference in AE, and the UUID of the persisted key pair in ID:

Response

{
  "AO": "RKPK",
  "AN": "Y",
  "AE": "8A51B8BD",
  "ID": "012184d3-06f1-0006-0001-5223386dde23",
  "RC": "<hex>",
  "SD": "<hex>",
  "DS": "<hex>"
}

RC holds the private key encrypted under the selected major key, not the private key in the clear. The usable private key never leaves the HSM.

Record the key name and the returned ID. If key generation fails, log the intended key name and stop the workflow, so an operator can confirm no orphaned key was left behind.

Generate the certificate signing request

Send RKOP with OP set to request to export a PKCS #10 request. Select the RKPK-generated key pair by name in NA and supply the subject fields. CryptoHub signs the request with the resident private key and returns it as hex-encoded DER in the RH token.

Request

{
  "AO": "RKOP",
  "OP": "request",
  "NA": "<key name>",
  "RT": "<common name>",
  "RO": "<country>",
  "RP": "<state or province>",
  "RQ": "<locality>",
  "RR": "<organization>",
  "RS": "<organizational unit>",
  "SC": "<email address>",
  "RG": "4",
  "SH": "trusted"
}

The tokens carry the following meaning. For the command reference, see RKOP: Request.

Token	Value	Purpose
`OP`	`request`	Export a certificate signing request.
`NA`	Key name	Selects the RKPK-generated key pair to sign with, by the name you assigned it.
`RT`	Common name (CN)	Subject common name.
`RO`	Country (C)	Subject country.
`RP`	State or province (ST)	Subject state or province.
`RQ`	Locality (L)	Subject locality.
`RR`	Organization (O)	Subject organization.
`RS`	Organizational unit (OU)	Subject organizational unit.
`SC`	Email address	Subject email address.
`RG`	`4`	Signature hash. On `RKOP`, `4` selects SHA-256.
`SH`	`trusted`	Keeps the private key stored in the HSM.

On CryptoHub 7.0.3.x, RKOP with OP=request accepts a key-name selector (NA) and the subject-override tokens above, so it builds the request directly from the RKPK-generated key pair. The RKOP: Request reference describes selecting an existing certificate by its CA container and name, which is the form later firmware uses. This guide documents the 7.0.3.x key-name form.

The numeric hash selector is not uniform across Host API commands. On RKOP, 1 is SHA-1, 2 is MD5, 3 is RIPEMD160, 4 is SHA-256, 5 is SHA-384, 6 is SHA-512, and 7 is SHA-224; omitting RG defaults to SHA-256. Other commands, such as RKGC, use a different table. Sending 2 here produces an MD5-signed request, which certificate authorities reject and which does not meet current signature policy. Use 4 for SHA-256, or omit RG. Never reuse an RG value across commands.

A successful response returns AN set to Y and the request in RH:

Response

{
  "AO": "RKOP",
  "AN": "Y",
  "RH": "308202623082014A020100301D311B3019..."
}

Subject alternative names (SANs) are not carried in the CryptoHub CSR generation command. AppViewX supplies SAN values to the certificate authority when it submits the request. The CSR itself therefore contains no SAN extension.

Decode the request

RH is hex-encoded DER, not PEM. Decode the hex to binary before submitting or inspecting it:

Shell

printf '%s' "<RH value>" | xxd -r -p > request.der
openssl req -inform DER -in request.der -text -noout

Confirm the decoded subject matches the values you requested, and that the signature algorithm is sha256WithRSAEncryption, before you submit the request to a certificate authority.

Next steps

Submit the request for issuance. See Submit the CSR to a certificate authority.

​Understand the bridge

​Generate the RSA key pair

​Generate the certificate signing request

​Decode the request

​Next steps

Understand the bridge

Generate the RSA key pair

Generate the certificate signing request

Decode the request

Next steps