Skip to main content
Run a single enrollment end to end, then confirm each stage did what it should. The checks below move from CryptoHub outward to the issued certificate.

​
Verify authentication

Authenticate as the endpoint identity and confirm the session is usable. Confirm the response returns a token and reports fullyLoggedIn as true. A session that is not fully logged in cannot run the key operations, and indicates the identity’s role requires more than one identity to authenticate.

​
Verify the key pair exists in CryptoHub

Confirm the key pair generated by the workflow is present in the key group you configured, under the name the workflow assigned. Check the following:
  • The key is in the expected key group, not in a default group.
  • The key name matches the naming convention the workflow applies.
  • The key type is RSA and the modulus size matches what was requested.
An RKPK-generated key pair is a PKI key pair. List it with PGKE: Paginated Keys, where its UUID appears in the KI column, and delete it with RKDP: Delete PKI Key Pair. The symmetric key commands return UNKNOWN KEY or KEY NOT FOUND for it even though it exists.

​
Verify the certificate signing request

Decode the request returned in RH and inspect it:
Shell
Confirm the following:
  • The subject matches the values submitted on the request form.
  • The signature algorithm is sha256WithRSAEncryption.
  • The public key algorithm is RSA and the modulus size matches the generated key.
Verify the request’s self-signature, which proves the CSR was signed by the private key that CryptoHub holds:
Shell
The response is similar to the following:
Shell
If the signature algorithm reads md5WithRSAEncryption, the hash selector was set to 2 rather than 4. Correct the workflow and reissue. Do not submit an MD5-signed request.

​
Verify the issued certificate

Confirm the certificate authority issued the certificate and that AppViewX recorded it. Check the following:
  • The certificate appears in the AppViewX inventory, in the certificate group selected on the request.
  • The subject matches the CSR subject.
  • The subject alternative names are present in the issued certificate, even though the CSR carried none.
  • The issuer is the certificate authority you selected.
  • The public key in the certificate matches the public key in the CSR.
Compare the two public keys directly:
Shell
Both commands print the same public key block. A match confirms the issued certificate belongs to the key pair CryptoHub generated.

​
Verify the private key never left CryptoHub

This is the outcome the integration exists to produce, so confirm it explicitly.
  • The AppViewX certificate record holds the certificate and the request, and shows no private key.
  • The private key is present in CryptoHub, in the key group, linked to the certificate.
  • No private key file was written to the AppViewX host during the workflow.

​
Clean up test objects

After a successful test, remove the objects the test created so they do not accumulate:
  • Delete the test certificate from the AppViewX inventory, and revoke it at the certificate authority if it was issued against a production certificate authority.
  • Delete the test key pair from CryptoHub with RKDP: Delete PKI Key Pair, using the key name or the UUID returned in ID.
Deleting a key pair is not reversible, and any certificate issued against it can no longer be used. Confirm the key is a test key before you delete it.