Verify the integration - Futurex Documentation

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:

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.

Standalone CA
Enterprise CA

Run these steps from an elevated PowerShell session on the AD CS server.

Get the CA configuration string:

certutil

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

Create C:\CA\test-request.inf with this content:

[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

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.

Create the request and submit it to the subordinate CA:

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

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

Issue the pending request. Replace REQUEST_ID with the request ID from the previous step:

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.

Retrieve the issued certificate:

certreq -retrieve -config "CA-SERVER\Example ML-DSA Issuing CA" REQUEST_ID C:\CA\example-issued-certificate.cer

CertReq saves the certificate to C:\CA\example-issued-certificate.cer, and the Certification Authority console lists it under Issued Certificates.

An enterprise CA requires that the AD CS server and the requesting computer are joined to Active Directory.

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.

On a computer in the domain, open the local computer Certificates console (certlm.msc) as an administrator.

Right-click Personal, and then select All Tasks > Request New Certificate.

On Certificate Enrollment, select Next. Select Active Directory Enrollment Policy, and then select Next.

Select Computer, and then select Enroll.

The enrollment result reports success and the new certificate appears in the selected Personal store.

In the Certification Authority console, expand the subordinate CA and select Issued Certificates.

The issued-certificates list contains the new certificate request.

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.

Verify the ML-DSA certificate chain

Run these commands against the test certificate file:

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.

​Confirm the CA provider binding

​Issue a test certificate

​Verify the ML-DSA certificate chain

​Confirm the CryptoHub operation

Confirm the CA provider binding

Issue a test certificate

Verify the ML-DSA certificate chain

Confirm the CryptoHub operation