Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP)

08/31/2016

8 minutes to read

In this article

Applies To: Windows Server 2012 R2, Windows Server 2012

If you have installed an enterprise or standalone certification authority (CA) that uses a Cryptographic Service Provider (CSP) for its private key, you might want migrate that key to a software Key Storage Provider (KSP). For example, this migration would then let the CA support the latest enhanced key storage mechanism and stronger key and signature algorithms for Cryptography Next Generation (CNG).

After the migration, you can then reconfigure the CA to issue certificates by using the SHA-2 hash algorithm rather than the less secure hash algorithm of SHA-1.

Use these instructions for a software Cryptographic Service Provider (CSP) and software Key Storage Provider (KSP) that ships with Windows Server for the versions that are listed in the Applies To list at the top of this topic. If your CA is running an earlier version of Windows Server, migrate to Windows Server 2012 or Windows Server 2012 R2 and then follow these instructions. If you use a CSP or KSP from another software or hardware vendor, contact the relevant vendor for the equivalent instructions. For example, this will be the case if you use a Hardware Security Module (HSM) to protect your CA key.

For all these procedures, you must use an account that is a CA administrator. On an enterprise CA, the default configuration for CA administrators includes the local Administrators group, the Enterprise Admins group, and the Domain Admins group. On a standalone CA, the default configuration for CA administrators includes the local Administrators group.

How to migrate a CA from a CSP to a KSP and optionally, from SHA-1 to SHA-2

Do these steps on the existing enterprise or standalone CA.

Backup the CA:

For Windows Server 2012 R2: First, open a Windows PowerShell window with the Run as administrator option, and then use the Backup-CARoleService cmdlet. For example:

For Windows Server 2012: First, open a command window, and then run the Certutil command with the backup option. For example:

Certutil –backup C:\CA-Backup

Note

If you prefer to use the Windows interface rather than these commands, from the Certification Authority console, right-click your CA. then choose All Tasks > Back Up CA and then follow the prompts in the wizard. Choose the options to back up the private key and CA certificate, and certificate database and certificate database log. Do not select the option to perform an incremental backup.

For all server versions: Then, in a Command Prompt window, run the following command to back up the CA registry settings:

In a Windows PowerShell session running with the Run as administrator option, run the following command to stop the CA service:

Stop-service certsvc

In a Command Prompt window, get the details of your CA certificates, by using the following command that you output to a file so that you can more easily make a note of the values for Cert Hash and Key Container, which you will need later:

Certutil –store my <Your CA common name> >output.txt

For example, if you run Certutil –store my "CorpSubCA" >output.txt and then open the output.txt file, you will see output similar to the following for each CA certificate that you have (you will have more than 1 CA certificate if it’s been renewed):

Using a Windows PowerShell session that is opened with the Run as administrator option, run the following command:

Cd cert:\localmachine\my

By using the first value that you identified earlier for the Cert Hash as the certificate ID when you ran the Certutil command, now run the following command to delete the certificate and private key:

Del –deletekey <"Certificate ID">

Repeat the previous step for all CA certificates that were identified when you ran the Certutil command.

Migrate the CA certificate and private key to a KSP:

From a Command Prompt window that you run as administrator, run the following command, referencing the .p12 file from your backup directory:

Certutil –csp <KSP name> -importpfx <Your CA cert/key file>

For example: Certutil –csp “Microsoft Software Key Storage Provider” –importpfx c:\Backup\CorpSubCA.p12. When you are prompted for a password, enter the password that you provided when you backed up your CA.

Then run the following command to export the resulting CA certificate and private key to a .PFX file:

Certutil –exportpfx my <CA Common Name> <PFX file path for export>

When you are prompted for a password, enter and confirm a new password.

Restore the exported .PFX file by running the following command on the CA:

Edit the contents, replacing <Your CA common name> with your CA common name. Because this is registry file, make sure that you also add Windows Registry Editor Version 5.00 and then a blank line before the registry path.

Before you save the file, confirm that you are using 3DES for the encryption algorithm by running the following command in a Command Prompt window:

certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm

The output will look similar to the following:

EncryptionAlgorithm REG_DWORD = 6603 (26115)

CALG_3DES

Algorithm Class: 0x6000(3) ALG_CLASS_DATA_ENCRYPT

Algorithm Type: 0x600(3) ALG_TYPE_BLOCK

Algorithm Sub-id: 0x3(3) ALG_SID_3DES

If you do not see 3DES in your output, modify the CNGEncryptionAlgorithm key value in the file to have the appropriate name.

Save the file and then run it:

EncryptionCsp.reg

Optional: Change the CA hash algorithm to SHA-2:

Note

This step is optional but recommended if your CA is using SHA-1 (or another, older hash algorithm) and requesting devices support the more secure SHA-2 algorithm. It might also be required to comply with the SHA-1 depreciation policy that is documented in the SHA1 Deprecation Policy post on the Windows PKI blog.

On the CA, in a Command Prompt window, run the following command:

certutil -setreg ca\csp\CNGHashAlgorithm <Hash Algorithm>

For example: certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Start the CA service by running the following command in a PowerShell session:

Start-service certsvc

Repeat these steps on all CAs in your environment that you want to migrate:

For subordinate CAs: You will not see this migration take effect on the CA certificate until you migrate the parent CA, and then renew the certificate for the subordinate CA.

For a root CA: You will not see the migration take effect for the CA certificate until you migrate the root CA, and then renew the certificate for the root CA.

Validating the new settings

These steps are optional but recommended so that you can validate the new settings are operational before the CA issues new certificates for production use.

To verify that the CA is configured for the correct key and provider

A successful response will include the line Provider = Microsoft Software Key Storage Provider

To verify that the certificate shows the correct signature algorithm and signature hash algorithm

Request and issue a certificate for a user or computer and inspect the resulting certificate details.

View the certificate by using the Certificates MMC snap-in and click the Details tab. The Signature algorithm and Signature hash algorithm should show the correct values for your CA configuration.

If you are using a standalone CA and the Certreq.exe command-line tool to request and retrieve the certificate, you can also use a Certutil command to view and validate the correct signing and hash algorithms. For example: Certutil issuedCert.cer | findstr /spi algorithm

To verify that the certificate revocation list publishes and has the correct signature algorithm and signature hash algorithm

Publish the certificate revocation list (CRL) by running the following command from a Command Prompt window on the CA:

Certutil –crl

Locate the CRL file (%windir%\system32\CertSrv\CertEnroll) and then run the following command: