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

# Validate and test

> Verify that AppViewX generated the key pair in CryptoHub, that the CSR was signed by the resident private key, and that the certificate issued correctly.

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.

<Note>
  An RKPK-generated key pair is a PKI key pair. List it with [PGKE: Paginated Keys](/Host_API/Commands/PGKE_Paginated_Keys), where its UUID appears in the `KI` column, and delete it with [RKDP: Delete PKI Key Pair](/Host_API/Commands/RKDP_Delete_PKI_Key_Pair). The symmetric key commands return `UNKNOWN KEY` or `KEY NOT FOUND` for it even though it exists.
</Note>

## Verify the certificate signing request

Decode the request returned in `RH` and inspect it:

```shell expandable lines wrap title="Shell" theme={null}
printf '%s' "<RH value>" | xxd -r -p > request.der
openssl req -inform DER -in request.der -text -noout
```

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 expandable lines wrap title="Shell" theme={null}
openssl req -inform DER -in request.der -verify -noout
```

<Check>
  The response is similar to the following:

  ```shell expandable lines wrap title="Shell" theme={null}
  Certificate request self-signature verify OK
  ```
</Check>

<Warning>
  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.
</Warning>

## 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 expandable lines wrap title="Shell" theme={null}
openssl req -inform DER -in request.der -noout -pubkey
openssl x509 -in certificate.pem -noout -pubkey
```

<Check>
  Both commands print the same public key block. A match confirms the issued certificate belongs to the key pair CryptoHub generated.
</Check>

## 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](/Host_API/Commands/RKDP_Delete_PKI_Key_Pair), using the key name or the UUID returned in `ID`.

<Warning>
  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.
</Warning>