Public Key Infrastructure (PKI) CA Private Key HSM Communication LossRoot CA Stops Publishing CRLs After HSM Network Outage

Question

Public Key Infrastructure (PKI) CA Private Key HSM Communication LossRoot CA Stops Publishing CRLs After HSM Network Outage

Mikko Hämäläinen 20

Hi everyone,

We have an offline enterprise Root CA whose private key is protected by a network-attached HSM. During a scheduled CRL publication window, the HSM network interface briefly went down while our network team was performing maintenance.

Connectivity has since been restored, and the HSM management tools can see the device normally. However, the CA still fails whenever we try to publish a new CRL and logs NTE_DEVICE_NOT_READY. Restarting the Certificate Services service doesn't seem to help. CNG/KSP logs suggest the provider is still holding a stale crypto session from before the outage.

Has anyone dealt with this before? What's the supported way to force the CNG KSP to establish a fresh session with the HSM without touching the existing CA private key or rebuilding the CA configuration?

0 comments

1 answer

Your answer

Answer 1

Hello @Mikko Hämäläinen

Since HSM connectivity has been restored but AD CS continues returning NTE_DEVICE_NOT_READY, I agree this points more toward the CNG/KSP session with the network HSM than CRL configuration itself.

I would first confirm the CA can still resolve and access its configured signing key:

certutil -getreg ca\csp
certutil -store my

You can also verify the configured provider/key information with:

certutil -getreg ca\csp\Provider
certutil -getreg ca\csp\CNGPublicKeyAlgorithm

Microsoft documents certutil for inspecting CA configuration and key/provider information.

The important point is that there isn't a generic Microsoft CNG command that safely tells an arbitrary third-party network HSM KSP to drop and recreate its authenticated HSM session. Session establishment, pooling, reconnect behavior, and recovery after an HSM outage are generally implemented by the HSM vendor's KSP.

I therefore wouldn't re-key the CA, change CACertHash, re-import the CA certificate, or rebuild AD CS. Those actions aren't justified while the existing CA key remains intact.

Instead, I would:

Stop Certificate Services:
```
   net stop certsvc
```
Follow the HSM vendor's documented KSP/session restart procedure. Depending on the vendor, this may involve restarting its local client/KSP service or reconnecting the HSM client.
Verify that the existing CA key/container is visible through the vendor's tooling.
Start AD CS again:
```
   net start certsvc
```
Test CRL generation:
```
   certutil -crl
```

If certutil -crl still returns NTE_DEVICE_NOT_READY while the vendor tooling can successfully access and perform operations with the same CA key, I'd capture the CAPI2/CNG and CertificationAuthority events and involve the HSM vendor first to determine whether its KSP is returning the error to certsvc.

I would avoid rebooting or reinstalling/re-registering the KSP until you've checked the vendor's recovery procedure. With an offline Root CA and HSM-backed private key, preserving the existing key association should take priority.

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