SHA1 to SHA2 Migration Needs, Prerequisites and available options

Published on
3,177 Points
Last Modified:
Freelancer, IT Consultant experienced on Microsoft server, AD and Messaging projects
This article explains SHA1 to SHA2 migration requirements in a simple way by putting all data on table, while explaining SHA1 and SHA2 algorithms, SHA1 deprecation plans and possible migration paths to SHA2.

Terminology Used:

SHA1 (Secure Hash Algorithm 1) - This is a cryptographic hash function which can produce a 160-bit hash from any length of data.

SHA2 (Secure Hash Algorithm 2) - This is a next-generation cryptographic hash function which can produce 224 to 512-bit hash from any length of data. Both, SHA1 and SHA2 algorithms were used with digital signatures, data integrity, and authenticity checks within PKI implementations

CSP - Cryptographic service providers are responsible for doing cryptographic operations such as generating digital keys, maintaining key storage. There are two types of CSPs. 

MS SCP - One is legacy provider such as "Microsoft strong cryptographic provider" which can produce 160-bit hash maximum (SHA1)

MS KSP - This is CNG (cryptographic next generation) cryptographic provider defined with Windows 2008 and above called as "Microsoft software Key storage Provider" or KSP. This provider is capable of producing 224 to 512-bit hash (SHA2)

Key pair  - The term is used widely in PKI as part of public-private key pair. The private key always remains with the owner and would not be shared with anybody and used for signing certificates, digital signatures, and encryption. The data encrypted by public key can be decrypted by corresponding private key and vice versa.

Hash Functions

Hash functions are used in PKI for digital signatures, data integrity checks and authenticity

Hash functions can take any size of data and produce a unique hash value.

Message integrity can be identified based on its hash value, if the hash value of the same data changes at the source and destination, it means the message has been modified in transit.

The hash can be produced with data inputs but should make extremely hard for intruders to produce the original data from the hash, this is known as one way hash function.

It is not possible, in a reasonable time, to find two different inputs, that produce the same hash value. This term is called collision-free.

SHA1 and SHA2 are known as hash functions (cryptographic function)

SHA1 History:

Before we get into SHA1 to SHA2 deprecation and migration details, we need to understand a short history of SHA1.


The SHA1 algorithm was designed by NIST in 1995 and it has become the global standard for public/private certificate authorities as a signing and hashing algorithm for the majority of certificate types. As Computer processing capacity increases day by day, due to technology upgrades, In 2005 three Chinese cryptographers proved that SHA1 was no longer collision-free. This meant that they had developed an algorithm faster than Brute force to find collisions. In other words, they could produce two different messages for which the SHA1 algorithm generates the same hash value.

In March 2006, NIST published a recommendation to stop using the SHA1 algorithm for digital signatures and that organizations should use SHA2 hash functions. NIST republished an updated recommendation to use SHA2 in Sep 2012 and Aug 2015 (https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions). So, it may be possible that certificates issued with SHA1 issuer may get compromised by man-in-the-middle attacks. If this happens, spoofing and data tampering is possible, because the hash value remains the same even if the original data is changed.

SHA1 produces 160-bit hash values whereas SHA2 produce 224 to 512-bit hash values which are much longer, and extremely difficult to break.

SHA1 Global Deprecation Policy:

According to Global standards, only *Root certification authorities* can have self-signed Root certificates with a SHA1 algorithm, but when it issues CRL's or certificates to the issuing CA or intermediate CA, it should use the SHA2 algorithm. Further intermediate CAs should hand out end certificates (SSL, code signing or client authentication and so on) using the SHA2 algorithm only. Note that public CAs never hand out certificates directly to an end entity and they must use intermediate CAs to hand out end certificates.  

Certificate signature is the way to identify its issuer and thus the trust chain. Since a root certificate is a self-signed certificate and the start entity in a chain, there is no issuer against which the signature needs to be verified. Hence SHA1 signed root certificates are still valid and not affected by the SHA1 deprecation plan yet.

For example: In the below SSL certificate chain for a publicly accessible web site, the root certificate is still signed with SHA1, while intermediate and end certificates are signed with the SHA2 hash function.

However, Public CA's are advised to renew their root certificates too, from SHA1 to SHA2, as part of the global security initiative and the process has already started for most public CA's.  Intermediate/issuing CA's must use a certificate with SHA2 and they must be able to hand out certificates with a SHA2 algorithm only.

In Nov of 2014, the Chrome browser started rejecting / warning for web sites with SHA1 signed certificates. Microsoft started warning customers starting July 2016 for web sites having SHA1 certificates with IE 11 / Edge browsers.

The below diagram illustrates what combination of SHA1 and SHA2 is allowed for public Certification authorities. The same logic will be applied to Microsoft internal certification services as well

Basically, all public CA's must adopt the SHA2 hash function for all cryptographic operations starting from root CA to end certificates except Root CA certificate which is self-signed and generated a long back ago with a SHA1 signature. However future renewal of Root certificates must use SHA2 only.

How to renew/change public CA's algorithms from SHA1 to SHA2 is out of scope for this document. In fact, details are not available for this configuration at this point in time, as far as I know.

Microsoft SHA1 Deprecation Plan:

As per this and this blog entry, Microsoft internal certification authorities won’t be affected with SHA1 deprecation. The deprecation initially applied to the Microsoft Root Certificate Program as per security advisory. However, the Microsoft road map is to remove SHA1 completely, in fact, this is in alignment with global changes to adopt and be compliant with global standards. Hence Internal certification authorities also must be transitioned from SHA1 to SHA2.

Note - Image is taken from Microsoft white paper

Microsoft first published this advisory bulletin in Nov 2013 to phase out SHA 1 hashing algorithm and it was updated on May 2016 and further on Nov 2017. The below statements are directly taken from the bulletin for reference.

Microsoft is announcing a policy change to the Microsoft Root Certificate Program. The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016. Using the SHA-1 hashing algorithm in digital certificates could allow an attacker to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.

Windows will no longer trust certificates signed with SHA-1 after January 1, 2017

Recommendation. Microsoft recommends that certificate authorities no longer sign newly generated certificates using the SHA-1 hashing algorithm and migrate to SHA-2. Microsoft also recommends that customers replace their SHA-1 certificates with SHA-2 certificates at the earliest opportunity.

For Microsoft certificate services (Enterprise PKI) on windows server technology, they have added SHA 2 signing support since Windows 2008 Server.  The majority of Microsoft operating systems since XPSP3 do support SHA 2 algorithm, also the majority of browsers recent versions, since 2015, also support SHA 256 encryption.  There might be applications which don’t support SHA 256 algorithm, for those apps, security architecture must be changed.

There might be client software which doesn't support SHA 2, for those one might install two certificates on the application if it’s supported. One certificate with SHA 1 to support older clients and one certificate with SHA 2 for modern clients. Apache web servers do support multiple/dual certificates.

Microsoft has specifically targeted TLS / SSL certificates and code signing certificates to be invalidated if they are signed with a SHA1 algorithm. Other types of certs like S-Mime certificates and client authentication certificates are still allowed but in the future, those might also get invalidated as part of a deprecation initiative. Third-party / old Windows applications that can use *only* older versions of Internet Explorer will not be impacted as those browsers are not compatible with SHA2

The below diagram shows allowed and recommended CA signing algorithm as of today for two-tier windows certificate services (Internal CA)


The above diagrams show currently accepted topology for Offline root CA servers, AD-integrated Enterprise root CA servers and Subordinate enterprise root CA servers. 

In case of an offline Root CA, the root certificate can remain SHA 1 but all signing operations should be carried out with SHA 2. This includes any Sub CA certificates or CRL's it signs or any end-entity certificates and CRL's issued by Subordinate CA to remain compliant.  In the case it is an Enterprise root CA (AD Integrated), the root certificate can be SHA1 alone, however, whatever end certificates or CRL's it issues must use SHA2 hashing algorithm to remain compliant.

Microsoft recommends to all their customers to renew SHA1 root certificates as well, hosted on internal certificate servers to avoid future vulnerability, if any.  Note that converting CA signing algorithm from SHA1 to SHA2 won't renew the CA certificate itself. CA certificates need to be manually renewed and renewing the CA certificate won't invalidate already issued certificates as they chain up to old CA certificate and remain valid until they expire or until they revoked manually and as long as the root certificate remains with their computer trusted root store.

There are a couple of options that are available to transition Microsoft internal certificate services from SHA1 to SHA2. 

Option1 - Deploy brand new Windows certificate services  

Implementation new windows certificate server infrastructure (PKI) with the latest server OS (2012 R2 and above) on SHA 2 with a key service provider (KSP) as the cryptographic provider. CA certificate along with signing operations would happen with a SHA 2 algorithm with CNG (cryptographic Next Generation – Cryptographic provider). Enroll all devices, servers, and users with SHA2 signed certificates from the new CA and gradually phase out all SHA 1 certificates and finally decommission the old SHA1 certificate authority.

Option 2 - Transition CA from SHA1 to SHA2 hash function when CSP is configured as "Key Storage Provider" (KSP)

If a new CA is deployed with a SHA 1 algorithm by mistake or to support legacy apps on the latest server OS (say 2012 R2), with KSP as the cryptographic provider, in that case, SHA 1 will be used for signing purposes. Microsoft has not yet retired SHA 1 from their server line for backward compatibility. In that case, we can simply change the CA config to use SHA 2 and restart the CA service

CA is using KSP as a cryptographic provider but hashing algorithm is SHA 1, as per MS deprecation policy, we need to upgrade the signing mechanism to SHA2

Run certutil.exe -setreg ca\csp\CNGHashAlgorithm SHA256 on CA server from elevated prompt, if the command ran successfully, restart the CA service.

Here now we can see that Hash algorithm is changed to SHA 256 (SHA 2), henceforth this CA will sign all new certificate requests, CRLs with the SHA 256 algorithm.  The root certificate is signed with SHA 1. This is acceptable since this is a self-signed certificate.  Renewing the root certificate from SHA 1 to SHA 2 is not mandatory (as of the date this article was written) but recommended. In the future, you may need to renew the root certificate as well if enforced by Microsoft / global platform.

Option 3: Transition CA from SHA1 to SHA2 hash function when CSP is configured as "Microsoft Strong Cryptographic Provider" (SCP)

If a CA is installed on 2003 server, Microsoft used SHA 1 as the signing mechanism with their “Microsoft Strong Cryptographic Provider” (SCP), In that case, first the CA needs to be migrated to 2008 R2 / 2012 / 2012 R2 server at least as these OSes do support CNG KSP SHA 2 cryptographic service providers. This is a mandatory requirement since 2003 server doesn’t support SHA 2 signing. CSP won't change automatically with the upgrade, it has to be done manually post-upgrade operation. The below links can be used for CA migration from 2003 to the latest OS




Once you have migrated the CA from 2003 to 2008 R2 / 2012 / 2012 R2, we can start SHA 1 to SHA 2 migration

For this demonstration, I am showing SHA 1 to SHA 2 transition for the Root CA and Subordinate enterprise root CA on 2012 server respectively.  The DEMO consists of two servers - Standalone root CA (AKA Offline Root CA) on Windows server 2012 Workgroup server and Subordinate Enterprise Root CA (ADCS) on windows 2012 domain joined member server. The transition must be started from Root CA and finish with the Subordinate CA

Transition Approach:

  1. On the root CA, backup the CA private key (its better to backup the CA database along with private key and parameters registry in case we need to restore the CA)
  2. Delete the CA private key
  3. Restore the private key from the backup taken and change CSP from SCP (SHA1) to CNG-KSP(SHA2) during the restoration
  4. Renew the Root CA certificate to make it SHA2 signed - optional
  5. Sign the new CRL file and publish the new CRL and renewed certificate with active directory
  6. For sub CA, steps 1 to 4 are the same. CRL and renewed certificate will be automatically published with active directory

Root CA:

Root CA is on 2012 server but still using "Microsoft strong cryptographic provider" (SCP) which can do SHA 1 signing only.

1).    Logon to the CA server as the local administrator and backup the CA certificate and database from an elevated command prompt. From the output, C:\CABackup\CCA.p12 is the private key of the CA. If the CA is renewed previously, multiple private keys will exists and all will be backed up with the above command. 

2).    Backup the CA configuration registry at HKLM\System\CurrentControlset\Services\Certsvc\Configuration

3).    Stop the Certificate service

4).    Run "Certutil -store my <CAName>" from the command prompt and ensure that CSP is the legacy provider (strong cryptographic provider -SCP)

5).    Delete the CA private key (Certificate) from local computer personal certificate store on the CA server. Note that if the CA certificate was renewed previously, you will find multiple private keys (certificates) in store and all those keys must be deleted.

6).    Run < Certutil -csp "Microsoft Software Key Storage Provider" -importpfx "Provide CA private key backup path" > command against the backed up CA private key to Change the CA cryptographic provider from CSP to KSP and import the certificate private key to the computer's personnel store. If the CA has multiple private keys due to previous CA certificate renewal, all keys will be imported.

IMPORTANT Note –  If the CA is installed on 2008 R2 server, the private key (backed up previously) must be copied on 2012 or above server and then execute above command. Certutil.exe version shipped with 2008 R2 and below OS cannot change CSP. Once the command is successful, we must export the private key (Mark Exportable) from 2012 server and import (again mark exportable) on 2008 R2 CA server.

7).    Run "Certutil -store my <CAName>" from a command prompt and ensure that the restored private key/s CSP is next generation provider (Key Storage Provider -KSP)

8).    Create reg files from below codes and import on CA server, replace “Your CA common name” with CA common name and import both registry files.

        a).    csp.reg

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\CSP]
"Provider"="Microsoft Software Key Storage Provider"


       b).    encryptioncsp.reg

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\EncryptionCSP]
"Provider"="Microsoft Software Key Storage Provider"

Now import both registry files

9).   Once we imported registry keys successfully, now we need to change cryptographic service provider to SHA 2 (SHA 256). This will enable CA to sign new certificate requests and CRL with SHA 2 hashing algorithm. Run the below command from an elevated command prompt on CA server

certutil -setreg ca\csp\CNGHashAlgorithm SHA256


Output should show old (SHA1) and new (SHA256) hashing algorithm

10).    Now start the certificate service

Now the CA hashing algorithm changed to SHA 256, but the CA certificate hash is still SHA 1.  We may renew this certificate so that new cert will be signed with SHA 256 hashing algorithm, this is an optional step.

11).    Update CRL, updated CRL will be signed by SHA256 hash function

We can see that new CRL is signed with SHA 256 algorithm

12).    Copy CRL file from Root CA (%SystemRoot%\System32\CertSrv\CertEnroll ) to domain controller and run " Certutil -dspublish -f <crl file path> RootCA "

Command completed successfully. If you get "DSConfigDN" error while executing the above command, you need to update "DSConfigDN" value of the root CA with active directory configuration container, 

Run < Certutil -setreg ca\DSConfigDN "DN of AD Configuration container" > on Root CA server to let it know that CRL needs to be published with active directory. The command will update "Published crl locations" attribute of CRL file with AD domain name you specified in the command.  Once the command is successful, restart the CA service.  Now update CRL again with "certutil -crl" command, command add AD configuration container information under CRL and then again publish this CRL file with active directory with the "DsPublish" command.

13).    If you have renewed the root CA certificate, then only the below step is necessary.

          Copy renewed root certificate file from Root CA (%SystemRoot%\System32\CertSrv\CertEnroll ) to domain controller and run " Certutil -dspublish -f <crt file path> RootCA "

Command completed successfully

Subordinate CA:

Now its time to transition Subordinate CA from SHA 1 to SHA 2.

We need to upgrade the Subordinate CA hashing algorithm to SHA 256 and need to renew the Subordinate CA certificate with SHA 256 to remain compliant as per global standard / Microsoft SHA 1 deprecation plan.

Steps are almost identical to Root CA with little change: 

  1. Backup the Subordinate CA database, private key and registry
  2. Stop the CA service
  3. Delete  the Subordinate CA Certificate (Private key/s) from MMC console
  4. Import  the Subordinate CA private key (certificate) from backup and convert its CSP from SCP to KSP
  5. Import CSP and EncryptionCSP registry keys
  6. Change CSP algorithm from SHA 1 to SHA 256
  7. Start the CA service
  8. Renew the CA certificate
  9. Sign the new CRL
  10. The new CRL and renewed certificate will be automatically published to AD as this is AD integrated CA

Post  Subordinate CA certificate renewal, CA will sign all certificates it issues with SHA256 and its own certificate is also signed with SHA256 by Root CA




I hope you will find this article useful. You are encouraged to ask questions, report any bugs or make any other comments about it below.

Note: If you need further "Support" about this topic, please consider using the Ask a Question feature of Experts Exchange. I monitor questions asked and would be pleased to provide any additional support required in questions asked in this manner, along with other EE experts...

Please do not forget to press the "Thumb's Up" button if you think this article was helpful and valuable for EE members.

It also provides me with positive feedback. Thank you!

Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free