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

# Verify the integration

> Issue a certificate through the ML-DSA subordinate CA and confirm the certificate chain, CNG provider binding, and CryptoHub signing operation.

Issue a test certificate and confirm that AD CS uses the CryptoHub-backed ML-DSA subordinate key.

## Confirm the CA provider binding

Run these commands from an elevated PowerShell session on the AD CS server:

```powershell theme={null}
certutil -getreg CA\CSP\Provider
certutil -key -csp "Futurex CryptoHub Key Storage Provider"
```

Confirm both results:

* The AD CS provider is **Futurex CryptoHub Key Storage Provider**.
* The provider enumerates the subordinate CA key from CryptoHub without a configuration, TLS, or authentication error.

## Issue a test certificate

Use the tab that matches the setup type you selected when you configured AD CS. A standalone CA has no certificate templates or enrollment policy, so it uses `certreq` instead of the Certificate Enrollment wizard.

<Tabs>
  <Tab title="Standalone CA">
    Run these steps from an elevated PowerShell session on the AD CS server.

    <Steps>
      <Step>
        Get the CA configuration string:

        ```powershell theme={null}
        certutil
        ```

        Record the `Config:` value, for example `CA-SERVER\Example ML-DSA Issuing CA`. The following steps use this value for `-config`.
      </Step>

      <Step>
        Create `C:\CA\test-request.inf` with this content:

        ```ini theme={null}
        [NewRequest]
        Subject = "CN=adcs-mldsa-test"
        KeyAlgorithm = RSA
        KeyLength = 2048
        ProviderName = "Microsoft Software Key Storage Provider"
        MachineKeySet = TRUE
        RequestType = PKCS10

        [EnhancedKeyUsageExtension]
        OID = 1.3.6.1.5.5.7.3.2
        ```

        <Note>
          The test certificate key does not need to use ML-DSA. The test confirms that the subordinate CA signs the certificate with its CryptoHub-backed ML-DSA key.
        </Note>
      </Step>

      <Step>
        Create the request and submit it to the subordinate CA:

        ```powershell theme={null}
        certreq -new C:\CA\test-request.inf C:\CA\test-request.req
        certreq -submit -config "CA-SERVER\Example ML-DSA Issuing CA" C:\CA\test-request.req
        ```

        <Check>
          CertReq reports a request ID and states that the request is pending. A standalone CA holds requests for administrator approval by default.
        </Check>
      </Step>

      <Step>
        Issue the pending request. Replace `REQUEST_ID` with the request ID from the previous step:

        ```powershell theme={null}
        certutil -resubmit REQUEST_ID
        ```

        Alternatively, in the Certification Authority console, expand the subordinate CA, select **Pending Requests**, right-click the request, and then select **All Tasks** > **Issue**.
      </Step>

      <Step>
        Retrieve the issued certificate:

        ```powershell theme={null}
        certreq -retrieve -config "CA-SERVER\Example ML-DSA Issuing CA" REQUEST_ID C:\CA\example-issued-certificate.cer
        ```

        <Check>
          CertReq saves the certificate to `C:\CA\example-issued-certificate.cer`, and the Certification Authority console lists it under **Issued Certificates**.
        </Check>
      </Step>
    </Steps>
  </Tab>

  <Tab title="Enterprise CA">
    An enterprise CA requires that the AD CS server and the requesting computer are joined to Active Directory.

    <Steps>
      <Step>
        In the Certification Authority console, expand the subordinate CA and select **Certificate Templates**. Confirm that the **Computer** template is listed. An enterprise CA publishes this template by default.

        If **Computer** is not listed, right-click **Certificate Templates**, select **New** > **Certificate Template to Issue**, select **Computer**, and then select **OK**.
      </Step>

      <Step>
        On a computer in the domain, open the local computer Certificates console (`certlm.msc`) as an administrator.
      </Step>

      <Step>
        Right-click **Personal**, and then select **All Tasks** > **Request New Certificate**.
      </Step>

      <Step>
        On **Certificate Enrollment**, select **Next**. Select **Active Directory Enrollment Policy**, and then select **Next**.
      </Step>

      <Step>
        Select **Computer**, and then select **Enroll**.

        <Check>
          The enrollment result reports success and the new certificate appears in the selected **Personal** store.
        </Check>
      </Step>

      <Step>
        In the Certification Authority console, expand the subordinate CA and select **Issued Certificates**.

        <Check>
          The issued-certificates list contains the new certificate request.
        </Check>
      </Step>

      <Step>
        In the Certificates console, right-click the new certificate, and then select **All Tasks** > **Export**. Export the certificate without the private key as `C:\CA\example-issued-certificate.cer`.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Verify the ML-DSA certificate chain

Run these commands against the test certificate file:

```powershell theme={null}
certutil -dump C:\CA\example-issued-certificate.cer
certutil -verify C:\CA\example-issued-certificate.cer
```

Confirm these properties in the output:

* The issuer is `Example ML-DSA Issuing CA` or your subordinate CA common name.
* The certificate signature algorithm is **ML-DSA**.
* Chain validation reaches `Example ML-DSA Root CA` or your CryptoHub root CA common name.
* CertUtil reports success.

## Confirm the CryptoHub operation

In CryptoHub, open the Microsoft ADCS service and confirm the service key store contains the subordinate ML-DSA key created by AD CS.

If any check fails, see [Troubleshooting](./troubleshooting).