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

# Troubleshoot Microsoft ADCS with ML-DSA

> Resolve ML-DSA discovery, CNG provider, CryptoHub authentication, subordinate-request, and AD CS startup failures.

Use the error at the failing boundary to separate Windows registration, CryptoHub connectivity, CertEnroll, and certificate-chain problems.

## ML-DSA is not available in CryptoHub

**Symptom:** **ML-DSA** does not appear in the certificate **Type** list, or the required parameter set is unavailable.

**Resolution:** Confirm that the HSM runs firmware 7.8.x.x or later and that CryptoHub runs 7.2.0.9 or later. Confirm that the selected HSM cluster contains the ML-DSA-capable HSM.

## AD CS reports that the provider type is not defined

**Symptom:** The AD CS configuration wizard or CertEnroll reports `NTE_PROV_TYPE_NOT_DEF` (`0x80090017`) or `NTE_NOT_FOUND` (`0x80090011`).

**Resolution:** The installed provider does not support a key property that AD CS requested. Download a new endpoint bundle from CryptoHub 7.2.0.9 or later, and reinstall the provider from that bundle:

```powershell theme={null}
.\cng-install.exe -overwrite
```

Close and reopen the AD CS configuration wizard after replacing the provider. If the error continues, contact Futurex support with `%windir%\certocm.log` and the provider log.

## Windows lists the provider but backend enumeration fails

**Symptom:** `certutil -csplist` shows **Futurex CryptoHub Key Storage Provider**, but `certutil -key -csp "Futurex CryptoHub Key Storage Provider"` reports a configuration, TLS, or authentication failure.

**Resolution:**

1. Confirm that `C:\Program Files\Futurex\cryptohub.json` is the first active configuration file in the CNG search path.
2. Confirm that every TLS file referenced by the configuration exists and that the AD CS service account can read it.
3. Confirm that the endpoint role permits the **REST API** port.
4. Confirm outbound TCP port 443 and the CryptoHub certificate trust chain.
5. Confirm that the endpoint credential in `cryptohub.json` remains active.

## The subordinate key cannot be created

**Symptom:** The AD CS wizard accepts the provider but fails when it creates the ML-DSA key. `%windir%\certocm.log` records the key-creation error.

**Resolution:** Confirm all of the following:

* The provider comes from an endpoint bundle downloaded from CryptoHub 7.2.0.9 or later.
* The selected provider option is `ML-DSA:44#Futurex CryptoHub Key Storage Provider`, `ML-DSA:65#Futurex CryptoHub Key Storage Provider`, or `ML-DSA:87#Futurex CryptoHub Key Storage Provider`.
* `global.key_protection` is `TRUSTED`.
* `cng.default_usages.asymmetric` contains `Sign` and `Verify`.
* The service key store and endpoint role allow key creation and signing.

To capture more detail, set `logging.file.path` in `cryptohub.json` to a directory that the CA service account can write to, set `logging.mode` to `INFO`, and run the wizard again.

## CryptoHub cannot sign the subordinate request

**Symptom:** Submitting the AD CS request under the CryptoHub root CA starts a failed job or reports that the root key cannot sign.

**Resolution:** Confirm that the root CA has **Anonymous Signing** security usage, **Sign/Verify** key usage, and a CA certificate profile. Confirm that the request uses ML-DSA-44, ML-DSA-65, or ML-DSA-87 and that the subordinate validity does not exceed the root validity.

## CertUtil cannot associate the signed certificate with the private key

**Symptom:** `certutil -installcert` reports `NTE_BAD_KEYSET` (`0x80090016`) or `CRYPT_E_NOT_FOUND` (`0x80092004`), or states that it cannot find the matching private key.

**Resolution:**

1. Confirm that the signed certificate came from the request generated on this AD CS server.
2. Confirm that Windows still registers **Futurex CryptoHub Key Storage Provider**.
3. Confirm that the provider can enumerate the original subordinate key from CryptoHub.
4. Confirm that the request and returned certificate contain the same ML-DSA public key.

Do not generate a replacement key after the root CA signs the request. A new key cannot match the signed certificate.

## The Certification Authority service does not start

**Symptom:** `certsvc` remains stopped after the subordinate certificate is installed.

**Resolution:** In Event Viewer, open **Windows Logs** > **Application** and find the most recent error from the **CertificationAuthority** source. Then confirm all of the following:

* The signed subordinate certificate is installed in the local-machine CA store, and the CryptoHub root is in the trusted root store.
* The AD CS server can reach CryptoHub on TCP port 443.
* The credential in `cryptohub.json` is current, and the CA service account can read `cryptohub.json` and the TLS files it references.
* `certutil -key -csp "Futurex CryptoHub Key Storage Provider"` lists the subordinate CA key without an error.

If the event reports `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`), see [The CA cannot check revocation for the subordinate certificate](#the-ca-cannot-check-revocation-for-the-subordinate-certificate).

## The CA cannot check revocation for the subordinate certificate

**Symptom:** `certutil -installcert` shows **Cannot verify certificate chain** with `CRYPT_E_NO_REVOCATION_CHECK` (`0x80092012`) or `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`). Or, the CA denies a certificate request, and `certutil -resubmit` reports `Disposition: 2 -- Denied` with the same error.

**Resolution:** Windows cannot get a CRL for the subordinate CA certificate. Choose one fix:

* **Publish a CRL.** Confirm that the subordinate certificate contains a **CRL Distribution Points** extension, that the CDP server publishes the root CA CRL at that URL, and that the AD CS server can reach it. To test, run `certutil -verify -urlfetch C:\CA\example-ml-dsa-issuing-ca.cer`. If the extension is missing, sign the subordinate request again. See [Configure the ML-DSA subordinate CA](./configure-ml-dsa-subordinate-ca).
* **Turn off revocation checking.** Set the `CRLFlags` values in [Turn off revocation checking](./configure-ml-dsa-subordinate-ca#turn-off-revocation-checking), and then run `Restart-Service certsvc`.

After you apply a fix, resubmit the denied request with `certutil -resubmit REQUEST_ID`, or submit a new request.

## Certificate enrollment fails after the CA starts

**Symptom:** The test certificate request fails even though the Certification Authority service is running.

**Resolution:** For a standalone CA, confirm that you issued the request from **Pending Requests** before you retrieved it. For an enterprise CA, confirm that the CA issues the selected certificate template and that the template permits the requester to enroll. Then correlate the Windows Certification Authority event with the CryptoHub service activity. If CryptoHub records no signing request, troubleshoot AD CS policy and provider binding. If CryptoHub records a rejected request, troubleshoot the endpoint identity, role, key usage, and key state.