AD CS losing HSM connection during CRL generation — NTE_DEVICE_NOT_READY

Martins Marco 0 Reputation points
2026-08-14T02:53:36.2266667+00:00

G'day,

We've got an Enterprise Root CA using a network-connected HSM, and it occasionally loses the HSM connection while generating a CRL. AD CS then throws NTE_DEVICE_NOT_READY and doesn't seem to reconnect cleanly.

Is there a supported way to re-initialise the CNG KSP session handles and force AD CS to reconnect to the HSM automatically, rather than restarting the CA service each time?

Anyone run into this before?

Windows for business | Windows 365 Enterprise

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Allan Solomon Mejia 3,840 Reputation points
    2026-08-14T20:22:44.7766667+00:00

    Hello @Martins Marco

    NTE_DEVICE_NOT_READY during CRL generation points more toward the HSM/KSP communication path than CRL publication itself. AD CS must access the CA private key through the configured CNG Key Storage Provider to sign the CRL; if the network HSM session has dropped, the signing operation can fail.

    I wouldn't recommend trying to manipulate or recreate CNG/KSP handles from AD CS. There isn't a documented AD CS command for forcing CertSvc to reinitialize an HSM provider session while keeping the existing CA service instance running. The provider/session recovery behavior is largely dependent on the HSM vendor's KSP implementation.

    A useful test when the problem occurs is:

    certutil -csplist
certutil -store my "<CA Common Name>"
certutil -crl

    certutil -csplist can verify that the KSP remains available, while the certificate-store output can help confirm that the CA certificate is still associated with the expected provider. Microsoft documents certutil -crl as the supported command for generating/publishing a new CRL.

    If the HSM vendor's diagnostic tools also fail to access the key at that point, I'd investigate the HSM connection itself: KSP/HSM client logs, network interruptions, session/time-out limits, firmware/client compatibility, and whether the vendor KSP supports automatic session reconnection.

    If the vendor KSP can't recover its session, restarting CertSvc may unfortunately be necessary to establish a fresh provider context. I wouldn't automate repeated CA-service restarts until the HSM vendor confirms that as their supported recovery mechanism.

    The fact that this occurs specifically during CRL signing is useful evidence, since Microsoft also recommends certutil -crl when validating that a CA's configured KSP/private key can successfully sign a CRL.

    If you can share the HSM vendor/model and KSP version, that would be the next important detail because session reconnection behavior is provider-specific.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?

    0 comments
  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.