Skip to main content
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:
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

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.
  • Turn off revocation checking. Set the CRLFlags values in 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.