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

# Before you start

> Review the CryptoHub, HSM firmware, Windows Server, access, and network requirements for an ML-DSA subordinate CA.

Confirm that CryptoHub 7.2.0.9 or later is installed before configuring the CA hierarchy.

## Supported versions

* CryptoHub 7.2.0.9

## CryptoHub access

Prepare the following CryptoHub resources and access:

* Two CryptoHub administrator identities for dual-control service and PKI operations.
* Permission to create certificate containers, root CAs, services, endpoints, roles, and key stores.

## Windows Server access

Prepare a Windows Server that has:

* Local administrator access for installing the AD CS role and registering the machine-wide CNG provider.
* Active Directory domain membership if you plan to deploy an enterprise subordinate CA.
* The AD CS Certification Authority role, or permission to install it during this guide.

## Certificate revocation

Before AD CS installs the subordinate CA certificate or issues a certificate, Windows checks whether the subordinate CA certificate is revoked. Windows needs a certificate revocation list (CRL) from the root CA to complete this check. If no CRL is available, the check fails with `CRYPT_E_NO_REVOCATION_CHECK` (`0x80092012`) and the CA denies certificate requests.

Choose one approach before you begin:

* **Publish a CRL (recommended for production).** Add a **CRL Distribution Points** extension to the subordinate CA certificate when CryptoHub signs it, and host the root CA CRL on a CRL distribution point (CDP) server at that URL. The AD CS server must be able to reach the URL.
* **Turn off revocation checking.** Configure AD CS to ignore missing revocation information. Use this approach only for test environments or when your PKI policy accepts the risk. AD CS cannot then detect a revoked subordinate CA certificate.

<Note>
  If you choose to publish a CRL, you are responsible for setting up and operating the CDP server. CryptoHub creates and exports the root CA CRL, but it does not host the CRL. Provide a web server that the AD CS server can reach, publish the CRL at the URL in the **CRL Distribution Points** extension, and publish a new CRL before the current CRL expires.
</Note>

## Network and TLS

Allow outbound TCP port 443 from the Windows Server to the CryptoHub FQDN. The CryptoHub Client Library uses the REST API over TLS.

<Warning>
  TLS inspection can replace the CryptoHub server certificate and break authentication. Exempt the CryptoHub FQDN from TLS inspection while keeping certificate and hostname verification enabled in `cryptohub.json`.
</Warning>

Confirm connectivity from an elevated PowerShell session:

```powershell theme={null}
Test-NetConnection -ComputerName cryptohub.example.com -Port 443
```

The result must show `TcpTestSucceeded : True`.

If you publish a CRL, also allow outbound traffic from the Windows Server to the CDP server. The port must match the URL scheme in the **CRL Distribution Points** extension, for example TCP port 80 for an `http://` URL.

## Files transferred between systems

Only public PKI artifacts cross the administrative boundary during CA enrollment:

* The AD CS subordinate certificate signing request moves from Windows Server to CryptoHub.
* The signed subordinate certificate and root certificate move from CryptoHub to Windows Server.
* Neither CA private key is included in these files.

Continue to [Prepare CryptoHub](./prepare-cryptohub).