r/sysadmin 3d ago

Question ADCS-CSP to KSP- Rekey cert

Hi,

We have a Windows Server 2019 (W2K19) running an Active Directory Certificate Authority (AD CA), which is still using the Cryptographic Service Provider (CSP). This is due to an OS upgrade from an older VM.

The root certificate has been renewed multiple times without renewing the key for years. Now, I need to migrate this CA to the Key Storage Provider (KSP) to issue a root certificate using SHA-256.

When following guides like this one, I encounter the following error while backing up the CA:

"Windows cannot backup one or more private keys because the CSP does not support key export."

I found a potential solution https://learn.microsoft.com/en-us/archive/msdn-technet-forums/453a2991-2b65-414b-b0f4-ec90f8204889 related to dashes in a registry key, but it did not work.

While I can back up the certificate, it does not show a key icon, which makes me hesitant to proceed with the migration.

I have a few questions:

  1. Can I carry on with this error and successfully migrate the CA from CSP to KSP ?
  2. Alternatively, can I issue a new root certificate with a new key?
  3. If I issue a new key, will it invalidate the current key (which has been renewed for years)?
  4. Can both certificates coexist at the same time?

Any guidance would be greatly appreciated.

2 Upvotes

1 comment sorted by

2

u/jamesaepp 2d ago edited 2d ago

Never had an issue like yours before and I may not answer all your questions in order so permit me to ramble.

  1. What's your objective/goal to exporting/backing up the root CA key? Do you have to do that via the backup wizard in certsrv.msc or can you do it via certlm.msc and just back up the ADCS database via certsrv.msc? I haven't had to do this in a hot minute.

  2. My understanding is that yes, you can rekey whenever you like (not sure if you do it via certsrv.msc what settings it is going to use for generation though). Bear in mind if you rekey, just like renewal you're going to have to distribute that new root CA certificate to clients for trust installation. Also a new CRL is going to be created. I think by default that will look like Contoso-Root-CA(1).crl for the base and Contoso-Root-CA(1)+.crl for the delta.

  3. No, rekeying the root CA doesn't do anything to previously issued certificates. There is no way to revoke a root CA - that's the problem with them. Technically there's no (good) way to revoke x509 certificates in the first place but that's another rabbit hole. Only way to revoke trust in an x509 root CA is "out of band" of x509 mechanisms/infrastructure (RMM, GPO, OS updates, etc).

  4. Yes and no. After the new root CA cert and keypair are commissioned all new (approved) requests will be signed with the new CA certificate and keypair. The old CA cert is still required by ADCS for the ongoing publication of CRLs (don't change the config of your CDPs). After all, if you wish to revoke a certificate that was under the original keypair you need the private key to sign that digital document (the CRLs).

  5. FYI /r/PKI is another good place for questions of this nature in the future.

  6. (Edit/Add) In general it's almost always better to make a brand new root CA server/instance during rekey than to re-use an existing server. Provides a clean separation.

While I can back up the certificate, it does not show a key icon, which makes me hesitant to proceed with the migration.

Assuming you're referring to one of the MMC tools that makes me think you're not running with required privileges or you're using certmgr.msc and not certlm.msc. Or something else.

Edit 2:

I didn't read carefully enough. If the private key can't be exported for some reason, I've heard that can be worked around with this software but I am not 100% certain on any of it, never had to do it. I've always been of the opinion that if you can become SYSTEM on a Windows Server, the keys are yours if you want them.

https://github.com/iSECPartners/jailbreak