Hello @NTT Terin
NTE_BAD_KEYSET during certutil -recoverkey usually indicates a problem accessing the private key for the KRA certificate needed to decrypt that archived key. Simply issuing or configuring a new KRA certificate doesn't repair older archived keys.
AD CS encrypts an archived private key using the public key of the KRA certificate active when the key was archived. Recovery therefore requires the corresponding KRA certificate and its original private key.
I'd first retrieve the archived recovery blob separately rather than attempting the entire operation in one step:
certutil -config "CA-SERVER\CA-NAME" -getkey <CertificateSerialNumber> archived.rec
The .rec file remains encrypted to the KRA certificate(s) originally used during archival.
Then, on the account/machine performing recovery, verify that the required KRA certificate is installed with its private key. You can inspect the certificate store and key association with:
certutil -user -store My
certutil -user -key
If the KRA certificate is present but its private-key association has been lost, certutil -repairstore may repair the certificate-to-key-container association provided the original private key still exists. It cannot recreate a missing KRA private key.
Once the correct KRA certificate/private key is available, retry:
certutil -recoverkey archived.rec recovered.pfx
Microsoft documents -RecoverKey specifically for decrypting an archived recovery blob into a PFX/PKCS#12 file.
The important part here is the re-keying. If the KRA was renewed/re-keyed with a new key pair, the new KRA private key cannot decrypt material archived using the previous KRA certificate. You must restore the old KRA certificate and its corresponding private key, normally from the KRA PFX/secure backup. Microsoft describes recovery as requiring the KRA private key that matches the public key contained in the archived recovery material.
I would therefore not modify the CA database or manually rebuild KRA objects/bindings yet. First, determine whether the original KRA private key still exists. Reconfiguring the CA with the current KRA affects future archival; it doesn't re-encrypt historical archived keys with the new KRA.
If the original KRA private key has genuinely been lost and the archived key was encrypted only to that KRA, there generally isn't a supported way to reconstruct it from the CA database—the CA stores the archived key encrypted to the KRA, while responsibility for retaining the KRA private key rests with the KRA.
If you can provide the exact output from certutil -recoverkey (including the full HRESULT) and confirm whether you still have the previous KRA certificate/PFX, that should tell us whether this is a broken key association or an actually missing KRA private key.
Sharing these references with you:
Microsoft - certutil and AD CS key recovery commands
Microsoft - Key Recovery Server process
Please "Accept the Answer" if this information helped you. This will help us and others in the community.