Как изменить алгоритм sha1 на sha256 в windows ca

This blog post is about migrating your Microsoft certification authority hashing algorithm from SHA-1 to SHA-2, to mitigate the risk from using the broken SHA-1 hashing algorithm and to comply with Microsoft SHA-1 deprecation plan.

In this blog post, I will be covering the following topics:

• SHA-1 is broken, time to migrate to SHA-2:
  • What a SHA-2 certification authority chain looks like?
  • Certification authority migration options.
• Cryptographic providers:
  • What are cryptographic providers?
  • Cryptographic APIs.
  • What this has to do with SHA-2?
  • Which provider my certification authority is using?
  • Is my certification authority capable of issuing SHA-2 certificates?
• Migrate your certification authority from CSP to KSP:
  • Introduction.
  • Backup is your big hero.
  • How we are going to make your CA use KSP instead of CSP?
  • Migration deep dive.

SHA-1 is broken, time to migrate to SHA-2

If you did not know yet, SHA-1 hash algorithm is a legacy cryptographic and is no longer secure. Attackers can use known weakness in SHA-1 to do man-in-middle attacks, compromise data integrity, or perform spoofing.

Microsoft, Google and others had announced their SHA-1 deprecation plans since 2011, to gradually shift from SHA-1 to SHA-2, a more secure alternative. Microsoft announced serious SHA-1 deprecation countdown that will start to take effect on May 9, 2017 according to their published whitepaper.

If you are not sure what SHA-1 deprecation means, how it might affect you, and whether you should do something about it, then kindly read my SHA-1 deprecation blog post and continue reading here to learn what is the next move.

What a SHA-2 certification authority chain looks like?

Before digging deep on how to migrate your certification authority hashing algorithm from SHA-1 to SHA-2, let us pause for a minute and try to picture where we want to be in terms of certification authority state. That is, how a PKI hierarchy would look like, that is not affected by the SHA-1 deprecation plans.

Microsoft SHA-1 deprecation plan affects the following enterprise PKI deployments:

• SSL and code signing entity certificates: These entity [end-user] certificates should be SHA-2 and the code signing certificates should be time-stamped.
• Intermediate certification authority certificate: The CA certificate for the CA server acting as the intermediate CA server (or issuing CA server).

Microsoft SHA-1 deprecation plan does not affect the following”

• Self-signed certificate of the Root certification authority server: This means that only the self-signed certificate for the Root CA can keep using SHA-1. Microsoft said “The SHA1 deprecation policy does not impact SHA1 privately deployed root certificates, because Windows relies on other means to validate root certificates besides the signature”
• All self-signed certificates: This is the case when you have a self-signed certificate that you are using internally or externally for some reason.

Let me give you an example. A 2-tier PKI hierarchy has an offline root CA and an online issuer CA [in a two-tier PKI hierarchy, the online issuer is also considered an intermediate CA server]. The online issuer CA issues end-entity certificates to users, computers and services.

In such two-tier PKI hierarchy, this is what it takes to be compliant with SHA-2 and avoid violation of the SHA-1 deprecation plan from Microsoft:

1. For the privately deployed root CA server:
   • The root CA self-signed certificate can either use SHA-1 or SHA-2, as it is not affected by SHA-1 deprecation plan.
   • When the root CA server signs a CRL, or signs a certificate request, this signing operation should be performed by SHA-2.
   • According to the previous point, the root CA server should be capable of performing SHA-2 operations even if its self-signed certificate is using SHA-1.
   • To do signing operations using SHA-2, the root CA should be using cryptographic provider that supports SHA-2 (i.e. Microsoft Key Storage Provider)
2. For the Intermediate Issuing CA server:
   • The CA certificate itself should be using SHA-2.
   • Any signing operation done by the server should be done with SHA-2.
   • To do signing operations using SHA-2, the issuing CA should be using cryptographic provider that supports SHA-2 (i.e. Microsoft Key Storage Provider)
3. For end-entity SSL and Code Signing Certificates
   • Should be using SHA-2, and the certificate chain should be using SHA-2 except for the root CA certificate, as the root CA certificate can use SHA-1 or SHA-2
   • For code signing certificates, a time-stamp should be included to validate the signature.

Here is what a PKI hierarchy might look like, in order to comply with the SHA-1 deprecation plan.

Here is what a PKI hierarchy might look like, that is affected by the SHA-1 deprecation plan.

Certification authority migration options

The time you spend in designing and planning the migration now, will pay off for many years. I read once that PKI is a 90% designing science, and 10% implementing. So, let us start by listing our migration plan options. I will be using a two-tier PKI infrastructure as an example in the migration options, and the same applies if you have more tiers.

Approach 1: “Side by Side migration using parallel PKI hierarchy with a different Root CA”

This is my favorite approach, as you will not be touching your current PKI hierarchy at all. Instead, you will establish a new hierarchy with a new root CA, and design that new hierarchy to support SHA-2 from the start. Gradually, you will start using the new hierarchy to issue all new certificates, and perhaps replace old certificates issued from the old hierarchy, with new certificates from the new one.

During this side-by-side migration, your end entities (servers, computers, services) should trust the new root CA certificate in addition to trusting the old one. The benefit of this approach is that you can carefully and slowly migrate applications to a new SHA-2 based PKI in a controller manner. Finally, when all subscribers (end-entities like computers, services and users) are now consuming certificates from the new PKI hierarchy, the old SHA-1 based PKI can be decommissioned.

Keep your current PKI infrastructure as is and deploy a parallel PKI infrastructure (on Windows 2012 R2 perhaps or later) that uses only SHA-2 for issued certificates and for CA certificates. Start issuing new certificates from the new hierarchy and re-issue SSL certificates from the new hierarchy.

In this way, you could keep your old PKI hierarchy to support legacy applications and devices that is not SHA-2 ready, while supporting SHA-2 completely in the new hierarchy.

If you are a professional PKI expert, then you might want to create a Certificate Policy (CP) document, for the adoption of SHA-2 and the discontinuation of SHA-1.

Approach 2: “Side by Side migration using same root CA server, and parallel Intermediate/Issuer CA servers”

Normally, your root CA server self-signed certificate is using SHA-1, and we know that this is fine and will not conflict with Microsoft SHA-1 deprecation plan.

But when the root CA needs to sign a certificate request or a CRL, it needs to do so using SHA-2. It might be confusing at first, I know. Again, if you look at the root CA self-signed certificate, you will find it using SHA-1. If the root CA wants to do an action from now on, like signing things, it must do so using SHA-2.

So, we can keep using the same root CA in our PKI hierarchy, but we need to make it a smart root CA, that is, capable of doing SHA-2 operations.

Next, we will create an intermediate/issuer CA server(s) that are chained to the same root CA. Those CA servers are SHA-2 capable from the start and running at least Windows 2012 R2 (as a recommendation). The below picture shows how this approach looks like.

For the root CA to be capable of doing SHA-2 operations, we shall migrate its operating system to one that supports SHA-2 (recommendation is Windows 2012 R2 or later). I wrote a blog post on how to migrate your certification authority root CA to Windows 2012 R2, that you can refer to.

You are still safe if your root CA is running Windows 2008 R2. Next you must check the cryptographic provider for your root CA, and make sure it is supporting SHA-2. Although the root CA certificate itself can be signed with SHA-1, the root CA still need to sign the CRL and the new Intermediate CA certificate request with SHA-2. You can know more about how to check the CA cryptographic provider SHA-2 support and how to upgrade to a provider that supports SHA-2 in this blog post. Now you have your root CA supporting SHA-2.

Cryptographic providers

Why it is a good thing to learn about this cryptographic provider thing, while we are talking about SHA-2 and migration options? Well, cryptographic providers play big role when it comes to supporting SHA-2 and the supported operating systems choice. Let me put it this way, your choice to move away from SHA-1 to SHA-2 depends directly on the type of cryptographic provider you are using in your environment.

What are cryptographic providers?

Now that you know how big the role cryptographic providers play when it comes to supporting SHA-2, let us introduce you to the concept of such providers. I will try to only mention basic things, and avoid using complex definitions and theories, as you can easily use your search skills to learn more.

A Cryptographic Provider is simply a component [software library usually] that performs cryptographic operations, generate keys, provides key storage functionality, and authenticate users. You can implement such providers in hardware, software, or both. It is like having a specialized security expert in the team, whenever you want to encrypt data, you go and ask him to do so, and you don’t need to know how he did it.

Again, I am going to give you simple uncomplicated picture of how to think about cryptographic providers. Imagine that a person called John [John represents an application that needs to do cryptographic operation], wants to purchase a new Kitchen. He can look at the market [Windows] and see what kitchen shops are available near him [Cryptographic Providers]. Each shop can deliver a unique kitchen style and options that distinguish it from other shops.

John does not need to worry about how to install a kitchen at his house, he only calls the shop that suites his taste, and ask them to do the installation. Each shop is specialized in installing a unique style and capabilities of kitchens. Now Alice [another application], John’s neighbor wants to install a kitchen at her house. She just need to pick a shop [cryptographic provider], and she can rest assure that the kitchen will be installed by professionals who know their job.

This is a simple idea I know, but it reflects what is happening in Windows. Applications need to do cryptographic operations, like creating and storing keys. They do not need to know the details of how this is being done, so they can look at what cryptographic providers are available in Windows and choose one to do the job.

Cryptographic providers specify the type, size and storage of key to be used. Each provider can support specific type, size and storage method for keys. Each cryptographic provider can do certain cryptographic functions. So, selecting a cryptographic provider can affect the cryptographic operations we can perform. If we want to use smart cards, then we need to choose a cryptographic provider that can store keys in smart cards.

Cryptographic APIs

Applications also do not talk directly to these provider, they use an API to do so. The original API that was used for this purpose is called Microsoft Cryptography API (CryptoAPI), which is now being replaced by a new version called Cryptography API: Next Generation (CNG).

This abstraction works well. Applications do not need to be concerned about security details, since cryptographic providers are responsible for implementing cryptographic algorithms and standards. Furthermore, one application can define which cryptographic provider it is going to use, by calling an API, that works as a bridge between the application and the provider.

As said before, there are two kinds of APIs that bridge communication between applications and cryptographic providers. Let us talk a little bit about these two APIs.

Microsoft Cryptography API (CryptoAPI)

Listen carefully, the cryptographic providers (those little things doing cryptographic operations), that are called by using the legacy CryptoAPI API are called Cryptographic Service Providers or CSP. So, CryptoAPI can call subset of the cryptographic providers in Windows, and those providers that can be called by CryptoAPI are called Cryptographic Service Providers.

Applications call the API (CryptoAPI), and that API calls one of the Cryptographic Service Providers to do some cryptographic operations.

In cryptography, two things matter:

• How to do cryptographic things (implement cryptographic algorithms).
• How to store keys (key storage).

Now those cryptographic providers used by CryptoAPI (a.k.a CSPs) are considered legacy ones. The same provider can do both operations, it can implement cryptographic algorithms and can also store keys. A list of those providers can be found here. An example of such CSPs are the Microsoft Base Cryptographic Provider v1.0 and the Microsoft Base Smart Card Crypto Provider.

Cryptography API: Next Generation (CNG)

It was first introduced in Windows Vista, and is currently the replacement for the CryptoAPI. It also does provide a lot more extensiblility and options like:

• It has kernel mode API that implements threat safety throughout the stack, provides process isolation for its operations and extensive auditing features.
• Backward compatibility with algorithms supported by CryptoAPI.
• Complies with FIPS 140.2 and supports the NSA Suite B Cryptography.
• Supports Elliptic curve cryptography (ECC) which is a new approach for public key cryptography where smaller keys are used for same level of security.
• Supports SHA-2 family which is the most important thing I believe.

Another thing to notice here is that this API adds another layer of abstraction. If you recall, the legacy CryptoAPI calls CSPs for both cryptographic algorithm implementation and key storage. Well, this API is built to talk to two specialized providers, one that can do only cryptographic operations, and one that can only do key storage.

So, imagine an application that wants to do a cryptographic operation, it calls the CNG API, which then will contact a provider from a specialized provider family [Cryptographic Algorithm Provider], that cannot do key storage operations, but they can do these cryptographic algorithms just fine.

Now, the application needs to do a key storage operation, it calls CNG API, which then will call a different provider from a different provider family [called CNG Key Storage Provider or KSP] to do key storage operations. An example of such KSPs are Microsoft Software Key Storage Provider and Microsoft Smart Card Key Storage Provider.

Simple enough, this API will call different providers when it comes to key storage vs cryptographic algorithm operations. The below figure shows this clearly.

In summary, we want to make sure we are using this new API, as it can call cryptographic providers that support SHA-2 functionality.

What this has to do with SHA-2?

Your certification authority should be using Crypto Next Generation (CNG) to support SHA-2. It is also worth mentioning that CNG was introduced in Windows Server 2008 and higher operating systems.

Two things we need to check here to ensure we can move to SHA-2 PKI hierarchy:

• We need to make sure that our certification authority server is running an operating system that can support CNG (which is Windows Server 2008 or later, but I recommend Windows 2012 R2 or later).
• We need to make sure the certification authority is using a Key Storage Provider (KSP) that supports SHA-2, like Microsoft Key Storage Provider , and not a legacy Cryptographic Service Provider (CSP) used by the legacy CryptoAPI.

Usually, people would have a certification authority deployed on Windows 2003 server, and then they upgrade the Windows version say to Windows 2008 R2. This means that the new Windows version supports CNG, but the certification authority might still be using the legacy CSP set of providers, and not the new KSP way. So, even if your CA is running on Windows 2008 R2 server, that does not mean your CA is using KSP. This happen when you upgrade the O.S from a legacy version that does not support KSP.

Moving forward, we want to go to our certification authority, make sure we have it installed on a Windows version that knows how to deal with CNG (Windows 2008 or later). Now that we know the CNG capabilities exist in the box, we still need to see if the certification authority is using such new capabilities (KSP) or just using the old ones (CSP).

Which provider my certification authority is using?

If your certification authority is running Windows 2003 or a previous version, then for sure you are using the legacy cryptographic providers (CSP). If you are running your certification authority on Windows 2008 or later operating system, then there is a good chance that you are using the new set of providers (KSP). To check which provider your CA is running, just go to your Microsoft certification authority console, then take a look at the General tab of the root CA’s properties and notice the value for the provider and the hash algorithm.

You can see from the picture above, that the cryptographic provider is Microsoft Strong Cryptographic Provider, which is as one of the CSPs used by the legacy CryptoAPI. This is bad as we know this provider cannot do SHA-2 operations. You can also note the hash algorithm in the picture as SHA-1.

You can also confirm this information by running Certutil –store my <Your CA common name>.

The hash algorithm is SHA-1 and the provider is Microsoft Strong Cryptographic Provider even on this Windows Server 2016 Server. This might be because this CA was upgraded from Windows 2003.

If you see in the below figure, you will see a CA using Microsoft Software Key Storage Provider (one of the KSPs). You can also see the hash algorithm as SHA256, which means that this CA will use SHA-2 to sign CA CRLs, and sign certificate requests.

Is my certification authority capable of issuing SHA-2 certificates?

The important question is whether your CA is capable of issuing SHA-2 certificates. By now you know that this depends on the cryptographic provider you are using, which depends on the Windows version your CA is running on.

Even if your CA is running a cryptographic provider that supports SHA-2, you still need to configure your CA to use SHA-2 for future signing operations.

Usually there are three steps that are needed to make your CA start using SHA-2 from now on:

Step 1: Check which cryptographic provider your CA is using

As shown in the previous section, you can know which provider your CA is running by inspecting the general properties of your CA from the certification authority management console, or by running Certutil –store my <Your CA common name>

Your provider should be one of the supported Key Storage Providers that calls Cryptography API: Next Generation (CNG) and not the legacy CryptoAPI CSPs. So if your CA cryptographic provider is one of those KSPs: Microsoft Software Key Storage Provider or Microsoft Smart Card Key Storage Provider, then you are good.

In summary:

• If your CA is using one of these cryptographic providers, then you are using the new CNG KSP (Key Storage Providers) that definitely supports SHA-2.
• If your CA is using one of these cryptographic providers, then you are using legacy CryptoAPI provider, which does not support SHA-2.
• Else, if you are using third party provider, you have to check with the supplier.

Step 2: Configure your CA to use SHA-2

Next, you need to configure your CA to start using using SHA-2 from now on to sign CRLs and certificate requests. On the CA, in a Command Prompt window, run the following command:

certutil -setreg cacspCNGHashAlgorithm SHA256

You might need to stop and restart the certificate services. Note also that this will not affect already issued certificates previously, but will affect any new issued certificate or CRL.

Step 3: Renew your CA certificate to use SHA-2

What about the CA certificate itself. You can check if it is using SHA-1 or SHA-2 by opening the CA certificate, and checking the Signature Hash Algorithm being used to sign the certificate.

As you can see, the CA certificate happened to be signed by SHA1. Now, we need to renew the certification authority certificate to use SHA-2. To do that, select your Certificate Authority and open the All Tasks line, Then select Renew CA Certificate

Accept the request to stop the Active Directory Certificate Service. You can choose to generate a new signing key.

Now, if we check the certification authority certificate, we can see it is using SHA-2. Mission accomplished.

Note: screenshots in this section is taken from Pierre Kennibol blog post.

Migrate your certification authority from CSP to KSP

This section will help you understand one specific scenario. Please skip reading this section if this does not match you case.

We are talking about a CA running Windows 2008 R2 or higher operating system that supports the new KSP providers, but the CA service is still using legacy CSP (cryptographic service provider).
This case is common and happen specially to root CA server. It happened when you migrate your CA from older operating system to a new one, and during the migration, you choose (use existing keys).

Say for example you have a root CA running Windows 2003, and you want to migrate that to Windows 2008 R2 operating system. You can easily backup the CA private key, database, and registry configuration, format the box with Windows 2008 R2, and start installing new certification authority on it. During the installation, you will be asked if you want to create a new key pairs or use existing ones. You would choose to use existing ones of course. Windows 2008 R2 will realize that those keys from your backup, are generated using a legacy CSP, so Windows 2008 R2 will use the same legacy CSP to host your CA private key. Hence, you will be running Windows 2008 R2 that can use KSP, but instead it will use legacy CSP.

This blog post is dealing with say a CA running Windows 2012 R2, and still using legacy CSP. We want to make this CA uses KSP instead. We are not migrating or upgrading the O.S, we just want the same CA to use KSP instead of CSP.

If you are running a CA on Windows 2008 R2, do me a favor and upgrade it to Windows 2016 or at least 2012 R2. This is not a requirement as Windows 2008 R2 supports KSP, but it will make your life easier.

Introduction

Let us review what we know so far:

• Knowing if your CA is using legacy CSP or the new KSP cryptographic provider makes all the difference, as only the new KSP providers support SHA-2.
• If your CA is running any Windows O.S version before Windows 2008 R2, then you should stop reading, and do yourself a favor, and upgrade your CA to the latest Windows version (at least Windows 2012 R2). You can read how to migrate your certificate authority root CA to Windows 2012 R2 in my previous blog post.
• You can be in a scenario where you are running a new operating system like Windows Server 2016 or 2010 R2, but your CA is using a legacy CSP. In other words, having your CA running on new operating system, does not mean that your CA is taking advantage of this and is using the new KSP providers. This can happen if you upgraded your CA from previous Windows version over the years.
• It is not enough that your Windows version is new, and your CA is using the new KSP provider, you still need to configure your CA to use SHA-2 as illustrated previously in this blog post.

Backup is your big hero

Before doing anything to your CA, make sure to back up your certification authority. Let me give you quick hint here. All what the CA cares about when it comes to backup are three parts:

• The CA private key.
• The CA database (contains list of issued and revoked certificates).
• CA configuration (listed under this registry key hklmsystemcurrentcontrolsetservicescertsvcconfiguration )

That’s it. You take care of those three things, and you can go to any server, and re-build your CA in no time. You can read more about certification authority backup in my previous blog post.

How we are going to make yout CA use KSP instead of CSP?

I will do some assumption here. If you are running your CA on Windows 2008 R2, then I will suppose you migrate it to Windows 2012 R2. Now, we have CA running on Windows 2012 R2, and still using legacy CSP. Our goal is to make it use KSP, and then configure it to start signing new requests with SHA-2. Please note that from now on, I will be describing my way of doing this, that is what worked well for me.

Giving these assumptions, here is a summary of my approach:

• Backup my CA server which is running Windows 2012 R2. Make sure you have the private key accessible to you for next steps.
• Delete the CA private key from your CA server.
• Create a new Windows 2012 R2 server with no roles on it. Then import the private key (from step 1) to the KSP provider on the new server (This is a temp server that we will use just to upgrade the key from CSP to KSP). This will make the private key KSP compatible.
• Export the key that was imported in Step 3. We will get now a KSP compatible private key.
• Go to your original CA server, and import the KSP compatible key, and specify KSP provider for key storage.
• Instruct the CA to start using SHA-2 for future signing operations.

Let me explain what is happening here. Your CA currently is running Windows 2012 R2 and using legacy CSP to store the CA private key. What we need to do is to export that private key and go to a staging area (by creating a temp Windows 2012 R2 server with no roles installed on it), and since Windows 2012 R2 comes with a KSP provider that we can use even without CA role installed, then we can import the private key to one of the KSP provider On that temp server.

This will make the private key stored on that temp server and using a KSP provider. Now, we will immediately export that key from the temp server by asking the KSP provider to give us the key back. It will do that, and we will get a KSP compatible key. So, we started with a CSP compatible key, and now we end up with a KSP compatible key, and the role of the Windows 2012 R2 temp server is done now.

Finally, we will go with that KSP compatible key to our original CA server. We want to make sure we deleted the private key from that CA first. Then we will import the KSP compatible private key to our CA server using a KSP provider.

The whole objective of the Windows 2012 R2 temp server is to convert the private key that is created using a legacy CSP, to a private key that is KSP compatible. We do that by importing the private key that was creating using legacy CSP, to the KSP provider on the temp server, and then export it again right away.

Migration deep dive

Let us start by quickly confirming which cryptographic provider our Windows 2012 R2 CA server is running by typing

Certutil –store my <Your CA common name>

As you can see, the provider being used is a legacy CSP called: Microsoft Strong Cryptographic Provider.

This means that the CA certificate private key is stored inside the operating system using the Microsoft Strong Cryptographic provider, which has specific technique in how to store keys.

Step 1: Backup your CA server, and keep the private key accessible for next steps

We talked in previous section on how to backup your CA server. What I want to do here is to make sure that you save your CA private key say at C:RootCA.P12. 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.

Step 2: Install a new temp Windows 2012 R2 server

Again, there is no reason to do that, but I prefer to do the key upgrade process on a different isolated Windows 2012 R2 server. We will call this the staging server from now on.

Step 3: Delete the private key from the CA server

Now that you have exported the private key to C:RootCA.P12 on the CA server, go a head and copy it to the staging server.

After that, we need to delete the private key copy from the certification authority server itself. To do that:

• 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>

• Delete the existing CA certificate and private key:
  • sing a Windows PowerShell session that is opened with the Run as administrator option, run the following command

Cd cert:localmachinemy

• 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”>

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.

Instead of doing all these commands, you can just go to the Certificates Computer Store>Personal, and manually deleting the CA certificate.

Do that for all CA private keys, in case your CA has more than one certificates (the case when you renew your CA certificate).

Step 4: Migrate the private key from CSP to KSP

Remember the private key of your CA from Step 1 that you stored in C:RootCA.P12, now move it to the staging server, and run the following command to import the key to the KSP provider on the staging server. Remember that the staging server does not have any roles installed. You do not need to have CA installed in the machine to store keys in KSP.

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

In our case, this would be

Certutil -csp “Microsoft Software Key Storage Provider” -importpfx C:RootCA.P12

When you are prompted for a password, enter the password that you provided when you backed up your CA.

What just happened? we took a private key that was created using a legacy CSP, and we called a KSP provider to store it on a Windows server. This will cause the key to be stored and be compatible with KSP. This is the whole magic. Now we will call KSP and ask it to export the key, and then we will go to our CA server and call KSP on the CA server to import it.

Now, we are still on the staging server, we will now call KSP to export the new KSP compatible private key by running:

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

In our case, this will be:

Certutil -exportpfx my "Corporate Root CA" C:newCert.P12

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 5: Configure the CA to use the new Key

Now take that C:NewCert.P12 from the staging server and copy it to your CA server, and run the following on your CA server:

Certutil –restorekey <PFX file path>

In our case, this will be:

Certutil -restorekey C:RootCA.P12

Step 6: Add CSP Registry Keys

Now, we need to create couple of registry files and run them at the CA server. Because it is extremely tricky to create a perfectly formatted registry key, I do the following:

I prefer you go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertsvcConfiguration<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_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration<Your CA Common Name>CSP]
"ProviderType"=dword:00000000
"Provider"="Microsoft Software Key Storage Provider"
"CNGPublicKeyAlgorithm"="RSA"
"CNGHashAlgorithm"="SHA1"

Do not forget to edit the contents, replacing <Your CA common name> with your CA common name.

Now before you carry on, just let us confirm that the CA was using SHA-1 as hashing algorithm before importing this registry file. To confirm that, run:

Certutil –v –getreg cacspHashAlgorithm

The output will look like this

HashAlgorithm REG_DWORD = 8004 (32772)
CALG_SHA1
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 7: 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_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration<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 caencryptioncspEncryptionAlgorithm

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.

Finally, save and run E2.reg

Step 8: 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 cacspCNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

References

-List of cryptographic providers and their supported functions.

-Microsoft documentation on how to migrate Windows CA from CSP to KSP and from SHA-1 to SHA-2.

-Microsoft documentation:Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP)