How To Migrate Your Certification Authority Hashing Algorithm From SHA-1 To SHA-2 - Ammar Hasayen

How to Migrate Your Certification Authority Hashing Algorithm From SHA-1 To SHA-2 | Ammar Hasayen 30/06/20, 10:29
How to Migrate Your Certification

Authority Hashing Algorithm From
SHA-1 To SHA-2
Ammar Hasayen Last updated Sep 21, 2019 | Published on Apr 19, 2018
Posted by | | PKI, Security | |
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?
https://blog.ahasayen.com/how-to-migrate-your-certification-authority-hashing-algorithm-from-sha-1-to-sha-2/ Pagina 1 di 42
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.
SHA-1 to SHA-2 3
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 ca\csp\CNGHashAlgorithm 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
hklm\system\currentcontrolset\services\certsvc\configuration )
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:\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”>
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_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\C
onfiguration\<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\Config
"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 ca\csp\HashAlgorithm
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_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Config
"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)

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 ca\csp\CNGHashAlgorithm 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)
Other Posts you might like
Blog Post Notification

Be the first to get notification when key blog post articles are released.
No marketing material.

How To Migrate Your Certification Authority Hashing Algorithm From SHA-1 To SHA-2 - Ammar Hasayen

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Migrate Your Certification Authority Hashing Algorithm From SHA-1 To SHA-2 - Ammar Hasayen

Uploaded by

Copyright:

Available Formats

How to Migrate Your Certification Authority Hashing Algorithm From SHA-1 To SHA-2 | Ammar Hasayen 30/06/20, 10:29

How to Migrate Your Certification

Posted by | | PKI, Security | |

This blog post is about migrating your Microsoft certification authority

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

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

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

Microsoft, Google and others had announced their SHA-1 deprecation

What a SHA-2 certification authority chain looks

Microsoft SHA-1 deprecation plan affects the following enterprise PKI

SSL and code signing entity certificates: These entity [end-user]

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

Self-signed certificate of the Root certification authority server:

In such two-tier PKI hierarchy, this is what it takes to be compliant with

1. For the privately deployed root CA server:

2. For the Intermediate Issuing CA server:

Certification authority migration options

Approach 1: “Side by Side migration using parallel PKI

During this side-by-side migration, your end entities (servers, computers,

Keep your current PKI infrastructure as is and deploy a parallel PKI

Approach 2: “Side by Side migration using same root CA

Normally, your root CA server self-signed certificate is using SHA-1, and

But when the root CA needs to sign a certificate request or a CRL, it

Next, we will create an intermediate/issuer CA server(s) that are chained

For the root CA to be capable of doing SHA-2 operations, we shall

What are cryptographic providers?

A Cryptographic Provider is simply a component [software library

usually] that performs cryptographic operations, generate keys, provides

Again, I am going to give you simple uncomplicated picture of how to

This is a simple idea I know, but it reflects what is happening in Windows.

Cryptographic providers specify the type, size and storage of key to be

then we need to choose a cryptographic provider that can store keys in

This abstraction works well. Applications do not need to be concerned

Microsoft Cryptography API (CryptoAPI)

Listen carefully, the cryptographic providers (those little things doing

API are called Cryptographic Service Providers or CSP. So, CryptoAPI

In cryptography, two things matter:

How to do cryptographic things (implement cryptographic

Now those cryptographic providers used by CryptoAPI (a.k.a CSPs) are

Cryptography API: Next Generation (CNG)

It was first introduced in Windows Vista, and is currently the replacement

So, imagine an application that wants to do a cryptographic operation, it

Now, the application needs to do a key storage operation, it calls CNG

What this has to do with SHA-2?

We need to make sure that our certification authority server is

Usually, people would have a certification authority deployed on Windows

Moving forward, we want to go to our certification authority, make sure

Which provider my certification authority is

the new set of providers (KSP). To check which provider your CA is

The hash algorithm is SHA-1 and the provider is Microsoft Strong

Is my certification authority capable of issuing

Even if your CA is running a cryptographic provider that supports SHA-2,

SHA-2 from now on:

Step 1: Check which cryptographic provider your CA is

If your CA is using one of these cryptographic providers, then you

Step 2: Configure your CA to use SHA-2

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

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

As you can see, the CA certificate happened to be signed by SHA1. Now,

Now, if we check the certification authority certificate, we can see it is

Migrate your certification authority from CSP

We are talking about a CA running Windows 2008 R2 or higher operating

easily backup the CA private key, database, and registry configuration,