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)
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)
AND / OR
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
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.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\CSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGHashAlgorithm"="SHA1"
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\EncryptionCSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGEncryptionAlgorithm"="3DES" "MachineKeyset"=dword:00000001 "SymmetricKeySize"=dword:000000a8
Now import both registry files
9).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
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
Steps are almost identical to Root CA with little change:
Post 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!