In this blog post, I will be talking about [Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP)], inspired from Microsoft TechNet Article talking about the same topic. I will try to give you more information and more examples about this topic, and how this plays big role in your journey to phase out SHA-1 and start using SHA-2
Please read the following topics before continue reading this blog post:
I will not discuss why and when you should migrate from CSP to KSP. However,I will only talk about the steps needed to migrate. 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
The below procedures Applies To: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
It can happen that your CA is using legacy CryptoAPI provider even if your CA is running Windows 2012 R2. Let me give you an example. Suppose you have a Root CA running on Windows 2003. You decided to upgrade that CA to Windows 2008 or higher (let us assume you did the upgrade to Windows 2012 R2). After the upgrade [check this post on how to upgrade your root CA O.S version], you will notice that the Certification Authority Service on this Windows 2012 R2 is using legacy CryptoAPI provider [like Microsoft Strong Cryptographic Provider]. This is normal since the private key of the CA was created using that legacy provider when you first installed the CA services on Windows 2003. Now when you perform the migration to Windows 2012 R2 CA, and during the CA installation on Windows 2012 R2, the installation will prompt you : do you want to use new private keys or existing ones? , and you answered that you want to use existing ones, and you point to the backed up private keys of your Windows 2003 CA. When you do that, the installation wizard will see that those keys are created via legacy provider, so a legacy provider will be used by the Windows 2012 R2 CA.
How this is done?
You take the private key that was issued by legacy CryptoAPI , you import it to Key Storage Provider (KSP) on Windows 2012 or Windows 2012 R2.
Now you export it again from the KSP to PFX file, and it is now KSP compatible if I may say that and you can import it back to your CA.
So you have your Winodws 2008 or Windows 2008 R2 server, you check what provider your CA is using, and you discovered it is legacy crypto provider (Details below on how to check this).
Although Windows 2008 R2 and Windows 2008 support the new Key Storage Providers (a.k.a KSP), the private key of your CA is still using a legacy provider that does not support SHA-2. This is possible because of many reasons, one of them if you have your PKI set up since Windows 2003 and you upgraded the CA to new Windows version that supports KSP, but the key itself is never upgraded. The private key itself is still generated using the old provider.
The first thing i would do is to upgrade my CA to Windows 2012 or 2012 R2 (THIS IS NOT REQUIRED, but will make your life easier in the next steps).
Once this is done, you will export the private key from your CA, and copy it to Windows 2012 or 2012 R2 normal server with no roles installed on it.
Then while you are on the Windows 2012/R2 server, you will import that private key to the KSP certificate store if i may say that. This will makes your private key KSP compatible.
The next step is to export that private key as it is now KSP ready, and import it back to your CA and mission accomplished. This will makes your CA private key able to use SHA-2. The next step is to configure your CA to use SHA-2. I hope this makes sense.
I faced some difficulties doing this, and upgrading my CA to Windows 2012/R2 before anything, makes my life easier. The blog post will go through all the steps. They may seem complicated but these are simple steps and easy to roll back any time.
What happen after configuring your CA to use SHA-2?
After your CA is configured to use SHA-2 for signing, the following will happen:
- Any newly issued certificate will be signed using SHA-2.
- Any new CRL issued will be signed using SHA-2
It is hard to answer the question about the effect of doing that. It depends on your applications and if they support SHA-2 and depends on how deep your PKI hierarchy is. The best way to go is to create parallel and separate PKI infrastructure to support SHA-2 and start issuing certificates from there and leave your old PKI infrastructure in place to support your old certificates. Also i recommend you read the last part from this TechNet blog post.
Also in a TechNet Forum discussion, the advise is to move to a separate hierarchy.
Step 1: Windows O.S Version
First of all, Key Storage Providers only exit on Windows 2008 or later, so if your CA server is running previous version of Windows, then you cannot use KSP or CNG.
Another recommendation, if we are talking about the Root CA server, I personally prefer that you upgrade it to Windows 2012 R2. Steps to upgrade it are described here, and it will take you no time to perform the upgrade. Many steps mentioned here rely on Windows 2012/Windows 2012 R2.
I actually tried to configure a Root CA running Windows 2008 R2 to use KSP instead of CSP, but i have found difficulties. So I upgraded the root CA to Windows 2012 R2, and then I upgraded from CSP to KSP so easily.
Step 2: Which provider my CA is using?
Run the following command from CMD on your CA:
Certutil –store my <Your CA common name>
For example, if you run Certutil -store my “Corporate Contoso CA” , the output will look like this:
As you can see, the Provider= Microsoft Strong Cryptographic Provider. Is this a legacy CryptoAPI provider or new KSP CNG provider?
Also, if you open the properties of the CA name from the Certificate Console, you will see what Cryptographic Provider being used along with the hashing algorithm used to sign requests by this CA.
Step 3: Backup your CA
It is normal that you need to backup your CA before doing any changes. To backup the CA, you need to backup three things:
- CA Private Key
- CA Database Files
- CA Configurations stored in the registry
Another way to backup your CA is to take System State backup or Full Server Backup via Windows Backup.
Step 4: Delete the CA Private Key
Save your CA private key to C:\. To do that, open the Certification Authority Snap-in, right click the CA name > Back up CA..> choose only “Private Key and CA Certificate” > Browse to C:\ to store the private key. Now you have the private key with .P12 extension. Later on, we will use this key and I will refer to it by C:\RootCA.P12
Stop the CA service, by right clicking the CA name, and click Stop, or by running :
Now, in order to delete the CA private key, we need two values:
- Cert Hash value
- Key Container value
Both these values can be obtained from the command we performed earlier (Certutil –store my <Your CA common name>)
To perform the actual deletion of the CA private key, procedures are different according to the O.S version:
Windows 2012 and Windows 2012 R2
Open a Windows PowerShell window with the Run as administrator option, and then run:
Del –deletekey <Certificate HASH>
You can see form the figure above that I have opened PowerShell, then I’ve used the PowerShell Certificate Drive by typing (CD cert:\localmachine\my), which will browse to the computer store of the CA, and then I deleted the certificate by providing the hash value.
Now if you open the Certificates MMC snap-in, and browse to the computer certificate store >Personal. You will see that the private key of the CA certificate is deleted.
Windows 2008 R2
Here you need to do two things:
- Delete the certificate that you want to migrate itself from the Personal Computer Certificate Store. [Open Certificate Snap-In> Computer Store>Personal]
- Run this command from CMD [Replace the Key Container value with the one you obtained earlier] :
Certutil –csp <Your current CSP> -delkey <Key Container Name>
So in our case, you should run this :
Certutil –csp "Microsoft Strong Cryptographic Provider" -delkey "Corporate Root CA"
Step 5: Import the private key to KSP
Windows 2012 and Windows 2012 R2
Run this command:
Certutil –csp <KSP name> -importpfx <Your CA cert/key PFX file>
In our case,
Certutil -csp "Microsoft Software Key Storage Provider" -importpfx c:\RootCA.P12
The RootCA.P12 is the private key that we backed up in previous step before deleting the CA private key [Check Step 4 above]
Windows 2008 R2
Because this server version does not support converting the key, you must copy the backed up private key to a computer that does support this procedure – for example, a computer running Windows Server 2012 R2 or Windows Server 2012. However, you can also use a computer running Windows 8.1 or Windows 8. Then run the same command in the Windows 2012 section from this Step.
Step 6: Export the private key from KSP
Now that your Private key is imported to KSP, you have to export it so that it can be used by the CA. Run this command [while you are in Windows 2012 or Windows 2012 R2]:
Certutil -exportpfx my <CA Common Name> <PFX file path for export>
Now that you have C:\NewCert.P12 , this is the private key of your CA in the new KSP format if i may say that.
Step 7: Configure the CA to use the new Key
If you have originally Windows 2008 R2 CA, then copy the P12 PFX file that you exported [While you are on Windows 2012/Windows 2012R2] from the previous step to your Windows 2008 R2 CA, before moving on.
Run this command from CMD on your CA:
Certutil –restorekey <PFX file path>
So in our case, it would be Certutil -restorekey C:\RootCA.P12
Step 8: ADD CSP Registry Keys
In this step, make sure you create a perfectly formatted registry key file , I prefer you go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration\<CA Common Name>\CSP Registry key, and export that key to a registry file called E.Reg for example.
Now, open E.reg using notepad, Keep the header information [Windows Registry Editor Version XXX] , and delete anything else and replace it with the below:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\CSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGHashAlgorithm"="SHA1"
Now before you carry on, just let us confirm that the CA was using SHA-1 as hashing algorithm before importing this registry key.
To confirm that, run:
Certutil –v –getreg ca\csp\HashAlgorithm
The output will look like this
HashAlgorithm REG_DWORD = 8004 (32772)
Algorithm Class: 0x8000(4) ALG_CLASS_HASH
Algorithm Type: 0x0(0) ALG_TYPE_ANY
Algorithm Sub-id: 0x4(4) ALG_SID_SHA1
If you do not see SHA1 in your output, modify the CNGHashAlgorithm key value in the file to have the appropriate name.
Now save and run the E.Reg file.
Step 9: ADD CSP Encryption Registry Keys
Now rename the E.Reg file to E2.Reg file, keep the header information and delete anything else and replace it with:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\EncryptionCSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGEncryptionAlgorithm"="3DES" "MachineKeyset"=dword:00000001 "SymmetricKeySize"=dword:000000a8
Before you save the file, confirm that you are using 3DES for the encryption algorithm by running the following command:
certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm
The output will look similar to the following:
EncryptionAlgorithm REG_DWORD = 6603 (26115)
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.
Finally, save and run E2.reg
Step 10: Optionally, Change the CA hash algorithm to SHA-2
Now that your CA is using CNG KSP, you can instruct the CA to use SHA-2 whenever it signs something, like CRLs and Certificate requests. To do that, just run:
certutil -setreg ca\csp\CNGHashAlgorithm SHA256 net stop certsvc net start certsvc