Skip to main content
AppViewX submits the CryptoHub-generated request to your certificate authority and records the issued certificate in its inventory. CryptoHub takes no part in this step, and the private key stays where it was generated.

​
Configure the certificate authority connection

Configure the certificate authority in AppViewX as you would for any other enrollment, then select it in the workflow that generates the CryptoHub key pair. The integration is independent of which certificate authority you use. Both an internal enterprise certificate authority and a public certificate authority work, because AppViewX submits a standard PKCS #10 request. For guidance on preparing Microsoft Active Directory Certificate Services against CryptoHub, see Microsoft ADCS.
That guide covers protecting the certificate authority’s own signing key with CryptoHub, which is a separate concern from this integration. The two can be combined: the certificate authority key can live in CryptoHub while AppViewX also generates subscriber keys there.

​
Supply subject alternative names at submission

Because CryptoHub does not carry SANs in the CSR, AppViewX must add them when it submits the request.
Confirm that your certificate authority accepts SAN values supplied with the request rather than requiring them in the CSR extension. A certificate authority configured to take SANs only from the CSR issues a certificate with no SAN extension, which most TLS clients reject.
Where your deployment requires at least one SAN of a particular type, enforce that in the AppViewX request form rather than relying on the certificate authority to reject an incomplete request.

​
Submit the request

1
Confirm the decoded request carries the expected subject and a SHA-256 signature, as described in Generate a key pair and CSR in CryptoHub.
2
Submit the request to the selected certificate authority, including the SAN values and any template, profile, or product type the certificate authority requires.An enterprise certificate authority typically requires a certificate template. A public certificate authority typically requires a profile or product type, and may apply a fixed validity period.
3
Wait for issuance. If the certificate authority requires approval, the request stays pending until an approver acts.
4
Record the issued certificate in the AppViewX inventory, in the certificate group you selected for the request.

​
Confirm the key stayed in CryptoHub

After issuance, the certificate is in AppViewX and the private key is in CryptoHub. AppViewX holds the certificate and the request, not the key. Verify that no private key was written to the AppViewX certificate record. If AppViewX shows a private key for the certificate, the enrollment did not use the CryptoHub-generated key pair, and the certificate should be revoked and reissued.

​
Optional: import the issued certificate into CryptoHub

If you want CryptoHub to hold the issued certificate alongside its resident private key, import the certificate into a CryptoHub X.509 certificate container. This links the certificate to the key pair that signed its request, so the certificate and key live together under CryptoHub custody. The private key does not move; it was generated in the HSM and stays there.
1
Import the issuing certificate authority’s certificate into the container, so the chain resolves.
2
Import the issued end-entity certificate into the same container. CryptoHub matches it to the resident key pair by public key.
For the import procedure, see Import certificates.
This step is optional. AppViewX remains the certificate system of record whether or not you import the certificate into CryptoHub. Import it when you want CryptoHub to present the certificate linked to its key, for example to sign with it through the Host API later.

​
Next steps

Validate the integration end to end. See Validate and test.