> ## 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.
# Configure the ML-DSA subordinate CA
> Configure Microsoft AD CS to create an ML-DSA subordinate key through CryptoHub, sign its request with the CryptoHub root CA, and install the signed certificate.
Configure AD CS as an ML-DSA subordinate CA. AD CS creates the subordinate private key through the Futurex CNG provider, then CryptoHub signs the resulting certificate request with the ML-DSA root CA.
## Install the AD CS role
Skip this section if the **Active Directory Certificate Services** Certification Authority role is already installed but not configured.
Open PowerShell as an administrator and install the Certification Authority role and management tools:
```powershell theme={null}
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
```
Confirm the role state:
```powershell theme={null}
Get-WindowsFeature ADCS-Cert-Authority
```
The **Install State** is **Installed**.
## Create the subordinate CA request
In **Server Manager**, select the notification flag, and then select **Configure Active Directory Certificate Services on the destination server**.
On **Credentials**, select an account that meets the displayed requirements, and then select **Next**.
On **Role Services**, select **Certification Authority**, and then select **Next**.
On **Setup Type**, select **Standalone CA**, and then select **Next**.
Use **Enterprise CA** only when the CA server is joined to Active Directory.
On **CA Type**, select **Subordinate CA**, and then select **Next**.
On **Private Key**, select **Create a new private key**, and then select **Next**.
On **Cryptography for CA**, configure the CryptoHub-backed key:
* Select one of the following cryptographic provider options:
* `ML-DSA:44#Futurex CryptoHub Key Storage Provider`
* `ML-DSA:65#Futurex CryptoHub Key Storage Provider`
* `ML-DSA:87#Futurex CryptoHub Key Storage Provider`
* Leave **Key length** set to `192`.
* Leave **Hash Algorithm** set to `NoHash`.
* Leave **Allow administrator interaction when the private key is accessed by the CA** cleared.
Select **Next**.
On **CA Name**, enter the subordinate CA common name and distinguished-name suffix defined by your PKI policy. This guide uses `Example ML-DSA Issuing CA` in examples.
Select **Next**.
On **Certificate Request**, save the request to:
```text theme={null}
C:\example-ml-dsa-issuing-ca.req
```
Select **Next**.
On **CA Database**, confirm the database and log locations, and then select **Next**.
Review the configuration and select **Configure**.
The wizard should report "Configuration succeeded with warnings" along with the message below:
"The Active Directory Certificate Services installation is incomplete. To complete the installation, use the request file "C:\example-ml-dsa-issuing-ca.req" to obtain a certificate from the parent CA. Then, use the Certification Authority snap-in to install the certificate. To complete this procedure, right-click the node with the name of the CA, and then click Install CA Certificate. The operation completed successfully. Ox0 (WIN32: 0)"
The Certification Authority service remains unavailable until you install the signed subordinate certificate.
## Sign the subordinate request in CryptoHub
Transfer `example-ml-dsa-issuing-ca.req` to the administrative workstation used to access CryptoHub.
The request contains the subordinate public key and identity attributes. It does not contain the CryptoHub-protected private key.
In CryptoHub, select **PKI & CA** > **Certificate Management** and expand the certificate container that holds the ML-DSA root CA.
Right-click the root CA, and then select **Add Certificate** > **From Request**. Upload `example-ml-dsa-issuing-ca.req`.
The certificate window displays the subject and ML-DSA public-key information from the request.
Review **Subject DN** and the validity dates on **Basic Info**. The subordinate validity must end before the root CA expires.
On **V3 Extensions**, select the **Certificate Authority** profile.
If you publish a CRL, add the **CRL Distribution Points** extension. Skip this step if you turn off revocation checking.
1. Select **Add**, select **CRL Distribution Points**, and then select **OK**.
2. Leave **Critical** set to **No**.
3. Select **Add**, and leave the type set to **HTTP**.
4. Enter the URL where the CDP server publishes the root CA CRL, for example `http://crl.example.com/example-ml-dsa-root-ca.crl`. Then select **OK**.
Include the protocol (`http://`) in the URL. The **CRL Distribution Points** extension requires it.
The **V3 Extensions** table contains a **CRL Distribution Points** row.
Select **OK** to submit the request to the root CA.
After the job completes, the subordinate certificate appears beneath the ML-DSA root CA and reports **Valid**.
Right-click the subordinate certificate and select **Export** > **Certificate(s)**. Export it as an X.509 certificate to `example-ml-dsa-issuing-ca.cer`.
Right-click the root CA and select **Export** > **Certificate(s)**. Export the public root certificate to `example-ml-dsa-root-ca.cer`.
## Publish the root CA CRL
Skip this section if you turn off revocation checking.
Create a certificate revocation list (CRL) for the ML-DSA root CA in CryptoHub, and then publish it on your CRL distribution point (CDP) server. You provide the CDP server. Any HTTP web server that the AD CS server can reach can serve the CRL file.
The filename and path on the CDP server must exactly match the URL in the subordinate certificate's **CRL Distribution Points** extension.
### Create the CRL
In CryptoHub, select **PKI & CA** > **Certificate Management**, and expand the certificate container that holds the ML-DSA root CA.
Right-click the ML-DSA root CA, and then select **CRL** > **Create**.
Configure the CRL:
* Leave **Initial revision** set to `1`.
* Set **CRL period** according to your PKI policy. The CRL expires at the end of this period.
* Leave **First issue** set to the current date and time.
Select **OK**.
CryptoHub signs the CRL with the ML-DSA root key. The **Signature hash** and **Padding** values do not change the ML-DSA signature.
### Export the CRL
Right-click the ML-DSA root CA, and then select **CRL** > **Export**.
Configure the export:
* Under **CRL Period**, leave **Last Revision** selected.
* Set **Encoding** to **DER**.
* Leave **Format** set to **X509**.
* In **File**, enter the filename from the extension URL, for example `example-ml-dsa-root-ca.crl`.
Select **OK**.
When CryptoHub reports that it wrote the CRL, select **OK**. Save the file that your browser downloads.
### Publish the CRL on the CDP server
Copy the CRL file to the CDP server at the path in the extension URL. For example, for `http://crl.example.com/example-ml-dsa-root-ca.crl`, publish the file as `example-ml-dsa-root-ca.crl` at the web root of `crl.example.com`.
Confirm that the CDP server serves the file over the protocol and port in the extension URL, for example port 80 for an `http://` URL.
From the AD CS server, download the CRL from the extension URL:
```powershell theme={null}
Invoke-WebRequest http://crl.example.com/example-ml-dsa-root-ca.crl -OutFile C:\CA\example-ml-dsa-root-ca.crl
```
The file downloads without errors and is not empty.
Create, export, and publish a new CRL before the current CRL period ends, and after you revoke a certificate issued by the root CA. If the published CRL expires, AD CS cannot check revocation and denies certificate requests.
## Install the CA certificates in Windows
Transfer the two public certificate files to `C:\CA` on the AD CS server. You may need to create the `C:\CA` folder.
Open PowerShell as an administrator and add the CryptoHub root certificate to the local-machine trusted root store:
```powershell theme={null}
certutil -addstore -f Root C:\CA\example-ml-dsa-root-ca.cer
```
CertUtil reports that it added the certificate to the store.
If you publish a CRL, confirm that Windows can check the revocation status of the subordinate certificate:
```powershell theme={null}
certutil -verify -urlfetch C:\CA\example-ml-dsa-issuing-ca.cer
```
CertUtil retrieves the CRL from the CDP URL and reports no revocation errors.
Install the signed subordinate CA certificate and associate it with the key created by the AD CS configuration wizard:
```powershell theme={null}
certutil -installcert C:\CA\example-ml-dsa-issuing-ca.cer
```
* **If you publish a CRL:** No warning appears. If a **Cannot verify certificate chain** warning appears, select **Cancel**, and then confirm that the AD CS server can download the CRL from the CDP URL.
* **If you turn off revocation checking:** A **Cannot verify certificate chain** warning appears and reports `CRYPT_E_NO_REVOCATION_CHECK` (`0x80092012`). This warning is expected. Select **OK** to continue.
CertUtil reports success and does not report a missing private key or provider error.
## Turn off revocation checking
Skip this section if you publish a CRL.
With these settings, AD CS issues certificates even when it cannot check whether the subordinate CA certificate is revoked. Use them only in test environments or when your PKI policy accepts this risk.
Run these commands from an elevated PowerShell session on the AD CS server:
```powershell theme={null}
certutil -setreg CA\CRLFlags +CRLF_REVCHECK_IGNORE_NOREVCHECK
certutil -setreg CA\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
```
* `CRLF_REVCHECK_IGNORE_NOREVCHECK` ignores missing revocation information, such as a CA certificate with no **CRL Distribution Points** extension.
* `CRLF_REVCHECK_IGNORE_OFFLINE` ignores a CRL that the AD CS server cannot reach.
CertUtil reports that it updated `CRLFlags`. The new values take effect when the Certification Authority service starts.
## Start the Certification Authority service
Start the Certification Authority service and confirm its state:
```powershell theme={null}
Start-Service certsvc
Get-Service certsvc
```
The service state is **Running**.
If the service was already running when you changed `CRLFlags`, restart it with `Restart-Service certsvc`.
Confirm the configured provider:
```powershell theme={null}
certutil -getreg CA\CSP\Provider
```
The provider is **Futurex CryptoHub Key Storage Provider**.
Continue to [Verify the integration](./verify-integration).