Information Security and Risk Management
By Roger A. Grimes, ISRM ACE Team, Principal Security Architect, email@example.com
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted
in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft,
our provision of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
The descriptions of other companies' products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee
their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.
© 2015 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express authorization of Microsoft Corp. is strictly prohibited.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Return to Top
Roger A. Grimes
The following Microsoft employees have reviewed this document and made recommendations that are included in this version
Mark Wilson, Senior Premier Field Engineer, Microsoft
Certificate Services Discussion List, Microsoft
Peter Geelen, Senior Premier Field Engineer, Microsoft
Download an offline copy of this article at the TechNet Gallery:
Many Microsoft Active Directory Certificate Services (ADCS) administrators are facing the decision of whether and when to create or migrate to the Secure Hash Algorithm version 2 (SHA-2) cryptographic hash function family within their private Public Key
Infrastructure (PKI) tree(s). This paper will discuss the importance of moving to SHA-2 and how to create or migrate to SHA-2 in ADCS.
This whitepaper supplements the reviewed and approved information found in Technet article
This section will discuss the importance of cryptographic hashes and the SHA family of hashes in particular.
Cryptographic hashes are used for digitally signing content for integrity validation, and are an integral part of any digital certificate. A hash function is "run against" supplied content to create a unique output set of bits (called the hash, digest, or
A good hash has many important cryptographic properties, including:
Cryptographically sound hashes have all these traits, plus are easy and quick to generate. A good hash allows input to be uniquely
fingerprinted at a particular point and time and then the input content can be copied or transmitted to other destinations and compared by receivers (using the same hashing algorithm) to see if the content changed between origination signing and destination
analysis. Without cryptographically sound hashing algorithms, digital authentication and integrity would be very hard to do (if not practically impossible).
In our particular interest, Certification Authorities (CAs) digitally sign every digital certificate and certificate revocation list (CRL) they issue, using hash functions. Certificate requests are also often signed by the requesting client. Every relying
(or consuming) application or device must be able to understand the hash used to do the digital signing.
Cryptographic Service Providers (CSPs) are the legacy built-in software routines used by Microsoft Windows for cryptographic analysis and manipulation. CSPs used the legacy built-in CryptoAPI (otherwise known as CAPI or CAPI1). CAPI has not been updated
since Windows XP/Windows Server 2003, so you will not see support for new ciphers, like SHA-2 and ECC, but it is still included in Windows (for now) for backwards compatibility purposes. Key Storage Providers (KSPs), were introduced in Windows Vista/Windows
Server 2008, and use the newer Cryptographic Next Generation (CNG) APIs. When you select a KSP, you are essentially switching Windows from using CAPI to CNG, and vice-versa.
Windows also has CAPI2. CAPI2 are higher level crypt32.dll APIs, which are meant to allow the crypto calling program to be somewhat independent of whether a legacy CSP or CNG KSP is used for key storage. CAPI2 APIs call CAPI1 or CNG APIs, respectively, depending
on whether a CSP or KSP is used.
A Windows application, involving cryptographic functions, will usually communicate with just one of the Windows cryptographic APIs: CAPI1, CAPI2, or CNG. If the application uses CAPI1, that application cannot support SHA-2 without modification. An application
communicating to CAPI2 or CNG can usually view and/or support SHA-2 signatures.
In Windows, you can see which hashing algorithm was used to signed a digital certificate, by opening the digital certificate, choosing the
Details tab, and looking at the value in the Signature hash algorithm field (see image below).
Note: The additional field called Thumbprint Algorithm, at the bottom of the details list, is unrelated to hash used to digitally sign the digital certificate. In ADCS, this particular field is usually SHA1 and is only related to the certificate's thumbprint.
The thumbprint can be used to identify or locate a particular certificate, but is not the hash the CA used to sign the certificate.
To verify the hash used to sign the digital certificate or CRL, export the digital certificate or CRL to a file and run the following command on it:
Certutil.exe [filename of digital certificate or CRL] | findstr /spi algorithm
Here's example output based on the certificate above:
Algorithm ObjectId: 1.2.840.113518.104.22.168 sha256RSA
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113522.214.171.124 RSA (RSA_SIGN)
You cannot see the digital certificate's hash signature in a Windows GUI. To see the digital certificate's hash signature, export the digital certificate to a file and run the following command on it:
Certutil.exe [filename of digital certificate]
In the output, which contains many hashes, you will see several fields beginning with the text,
Cert Hash, followed by the names of the hashes and the digital certificate's hash signatures. Here's an example related to the above certificate:
Cert Hash(md5): 62 95 30 0c 4e 30 12 17 3a 54 58 16 d2 64 85 09
Cert Hash(sha1): 9f 94 c4 d4 8f 43 d8 bf 7a 48 49 3a d8 7b 3d 0f 95 e3 c4 7d
Cert Hash(sha256): acbc8cd3c4886bbe1dd142127ba6b5c22219e03e70417926320a67d447b20174
Note that a certificate can be hashed by any algorithm at any time and the outputted hash digest obtained. Enabling a SHA-2 hash, like SHA-256, in ADCS ensures that the SHA-256 hash is precomputed by the CA for the issued digital certificate or CRL and be
used for verification purposes. Relying consumers can view the original SHA-2 hash fingerprint created by ADCS when the certificate or CRL was created, and then compare it a newly generated SHA-2 fingerprint that they compute and accurately determine the integrity
of the object.
You can check to see what hash your CA is currently configured to sign with by opening an elevated command prompt and typing the following commands:
certutil -getreg CA\CSP\CNGHashAlgorithm
It will probably say either SHA1 or SHA256.
You can see which Cryptographic Storage Provider or Key Storage Provider your CA is currently using by typing:
certutil -getreg CA\CSP\ Provider
Note: Running certutil.exe -getreg (view) or certutil.exe -setreg (setting) lets you view or set the registry keys where some ADCS configuration data is stored, HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\. Alternately,
you can use a registry editor to directly view and change the registry settings.
WARNING: Using a Registry Editor incorrectly can cause serious operational issues. Microsoft cannot guarantee that problems resulting from the incorrect use of a Registry Editor can be solved. Use a Registry
Editor at your own risk.
Hash signatures may or may not be checked by the underlying consuming application or operating system. Microsoft Windows contains the hash verification code, and most Microsoft applications rely upon the Windows OS to do the hash verification (when called
to do so by either the OS or application). Other OSs may have hash verification code as well and be used by relying on applications. Other applications may contain their own code. When determining where or whether hash verification is done, each specific scenario
must be analyzed.
Cryptographically sound hash algorithms should resist unexpected collisions. A hash collision could mean that a malicious actor could either independently generate/verify the original input even without seeing the original input or could create different
content that generates the same hash output and fraudulently substitute the other content in place of the original content.
(Note: When brute force guessing cryptographic secrets, an attacker is statistically going to find the correct hash in half the bit space, on average, when multiple rounds of attacks are done).
A good hash purports to have collision protection to at least half the number of bits of its digest function. For example, if a hash has 100-bits of protection, it normally expected that a successful attack cannot be generated until 250 guesses
have been tried. Any cryptographic attack which successfully finds a collision in less than half the bit space means the cryptographic function has a mathematical weakness. If that weakness significantly reduces the number of bits of protection, the cipher
may be considered weak or vulnerable. Hashes are among the hardest cryptographic functions to create and implement, and often fall to new cryptographic attacks over time.
SHA-1 (or Secure Hash Algorithm version 1) was designed by the United States National Security Agency (NSA) and published as a federal standard (FIPS Pub 180-1) in 1995. SHA-1 produces a 160-bit message digest, which if cryptographically secure, means that
it would take a brute force guessing attack 280 tries to find a hash collision. Even in today's world of very fast and a multitude of cloud computers, 280 tries is considered non-trivial to create a useful attack.
In January 2011 (with publication of National Institute of Standards and Technology (NIST) document SP800-131A), SHA-2 (http://en.wikipedia.org/wiki/SHA-2) became the new recommended hashing standard. SHA-2,
is often called the SHA-2 family of hashes, because it contains many different length hashes, including 224-bit 256-bit, 384-bit, and 512-bit digests (each discussed and released in related NIST Federal Information Processing Standard documents). When someone
says they are using the SHA-2 hash, you really can't determine which bit length they are referring to based on the name alone, but currently the most popular one is 256-bits (by a large margin).
Starting in 2005, several theoretical attacks against SHA-1 have been publically documented. By 2012, SHA-1 attacks (http://en.wikipedia.org/wiki/SHA-1#Attacks) have theoretically reduced SHA-1's protection
from 80-bit maximum average to 57.5 - 61 bits of protection. Although there have been no known real (i.e. not just demonstrated using mathematical models) SHA-1 attacks, the reduced bit space is theoretically possible for a reasonable amount of money (just
under $3M, using non-specialized cloud computers, according to some estimates). The cost of computing power continues to fall over time, so most cryptographic experts expect the cost of creating a SHA-1 collision to become well within the reach for more attackers.
It is important to note that in most scenarios it is non-trivial to generate different content that will generate a hash collision with the original content which would also be understandable or useful to the attackers or consumers of the original information.
Most hash collisions are unlikely to generate fraudulent content which would be useful to an attacker. Thus it would take many additional rounds of computation to generate a useful attack, in most scenarios. However, the author of this article has seen useful
collisions created using older (but previously relied upon) hash functions (i.e. MD-5), which, if used, would be capable of committing useful fraud.
It is with this in mind that most cryptographic experts recommend that cryptographic consumers stop using SHA-1 and use something stronger. Most experts, including NIST and many software vendors, recommend using SHA-2 as soon as possible, which although
it shares some of the same cryptographic attributes as SHA-1, uses larger bit spaces and is more resilient to known attacks (http://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_validation).
Because attacks have been demonstrated against both SHA-1 and SHA-2, NIST has already selected the next recommended hash standard called SHA-3 (http://en.wikipedia.org/wiki/SHA-3). It is called SHA-3 even
though it does not share most of the same attributes (and weaknesses) of the previous SHA versions. It will likely become the next global standard when SHA-2 is considered overly vulnerable.
Unfortunately, anyone thinking of delaying their SHA-2 migration in hopes of being able to move directly to SHA-3 will be greatly disappointed. Widespread adoption of SHA-3 is probably half a decade off or more, whereas, widespread adoption of SHA-2 will
probably be required in the next two to three years.
You need to migrate your PKIs to SHA-2 because of the known cryptographic weaknesses of SHA-1 and the recommendation of NIST and other vendors to use SHA-2. Many different impacted computer vendors, including the operating system and browser vendors, are
now actively working to eliminate reliance on SHA-1 and replace it with SHA-2. Each affected active vendor has, or should have, their own statement and timetable on their migration to SHA-2. Or of course an impacted vendor could no longer be active (and thus,
their product could be stuck using legacy ciphers) or they could choose to ignore the SHA-2 push for one or more products and simply be impacted by the migration as it occurs.
In this author's experience (as of May 2015) many vendors are aware of the coming migration but have yet to test their products or are unable at this time to share their future SHA-2 migration plans. Other vendors seem unaware of the issue at all. In general,
most popular operating system and browser vendors have published statements and timetables.
In many instances, a customer's first experience with a SHA-1 deprecation issue will be Internet browser-related. Expect most Internet browsers to display graphical indicators, warning messages, or errors about SHA-1 signed digital certificates soon. There
is a fairly decent summary of the major browser vendor's position statements, here (http://cloudsites.rackspace.com/browsers-phasing-certificates-sha-1-encryption/).
Microsoft announced our stance on SHA-1 in multiple blog articles, including
In summary, as of now (May 2015), Microsoft's SHA-1 deprecation only impacts SSL and code-signing certs issued by CAs in the Windows Root Certification Program. Any CA not in that program will be treated as a private/enterprise CA and Microsoft's current
(as of 5/15/2015) SHA-1 deprecation policies does not apply. Microsoft's treatment of SHA-1 and its further deprecation will be discussed more at the appropriate future time.
Windows Server 2008 and Windows Vista (and later Windows operating systems) natively support the consumption and requesting of SHA-2 digital certificates. Windows Server 2003 and Windows XP are capable of supporting SHA-2 with the latest service packs and
patches applied. Windows XP SP3 gives XP the ability to consume SHA-2 certificates, but Windows Server 2003 SP2 will need an additional patch (KB968730). Both Windows Server 2003 SP2 and Windows XP SP3 need KB968730 (https://support.microsoft.com/en-us/kb/968730)
to request SHA-2 signed certificates from Windows Server 2008 ADCS and later versions. Earlier Windows versions do not natively support SHA-2.
Currently all enforcement will be performed only in user mode using the framework that Windows has for blocking weak cryptographic algorithms. This means enforcement checking will not be done on kernel-level drivers and programs.
Note: Even with appropriate SHA-2 patches applied to Windows Server 2003, Certificate Services on 2003 cannot create SHA-2-signed digital certificates or CRLs.
Even if Microsoft Windows supports SHA-2 digital certificates, it is still up to individual applications on whether to use Microsoft Windows built-in cryptographic processes for digital certificate inspection and verification. Each application using digital
certificates should be tested, end-to-end, to ensure that it supports SHA-2 hashes.
Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when that certificate itself is SHA2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message
itself is SHA2 signed (regardless of the certificate used). Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot sign a message with SHA2; only SHA-1 and MD5 are available. In order to validate SHA2 messages, Windows Vista with Outlook
2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.
http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx for more detailed information and recommendations.
Here is the list of supported or non-supported SHA-2 Microsoft applications collected so far by this author.
This table describes which hash algorithms are supported for code signing for the following files formats and Windows versions:
Windows Server 2012 RTM/R2
Windows Server 2008 R2
Windows Server 2008
Portable Executable (PE) (.exe, .dll, .mui, .)
SHA1, SHA256, SHA384, SHA512
Multiple Signatures Supported
SHA1, SHA256 SHA384, SHA512
Authenticode Catalog (.cat)
Jscript / .VBS/ .WSF
Windows Installer (.MSI, MSP)
Note: Windows 8/Windows Server 2012 RTM and newer can verify multiple signatures bundled with the same PE or CAB file. PE files targeting these Windows versions and earlier should be signed with both SHA1 & SHA2 signatures so that the files can be verified
effectively on both.
Note: The Windows 7 kernel mode certificate verification logic supports only SHA1. Developers should sign PE files with SHA1/SHA2 multiple signatures, unless the file is confirmed to never be verified by the Windows 7 kernel.
ClickOnce Manifests are verified by the .NET framework. ClickOnce manifests are detached signatures that contain hashes of detached signed files and an embedded XML digital signature. ClickOnce manifest signature verification has a dependency on Windows
to verify the certificates and timestamp used to sign the manifest.
.NET 3.5 and below
.NET ClickOnce Manifest
Note: Timestamp support is limited to SHA1.
This is a small list of major vendors and their stated SHA-2 support statements. Check with each vendor's website to get a list of the current support statements.
Unfortunately, whether you use SHA-1 or SHA-2 is often an operationally dividing decision. Once you choose to install one or the other, all relying applications and connections to the same host have to accept the choice (in order to function without warning
or interruption). For example, if you install a digital certificate signed by a SHA-2 hash on a web server, only connecting clients which browsers understand SHA-2 will be able to connect (without warning or interruption), and vice-versa. If you stay on SHA-1
there will be future operational issues. Conversely, if you move to SHA-2, there may be operational issues with legacy software and devices.
Each company should do its own SHA-2 evaluation and determine which affected applications and devices can accept SHA-2 certificates, and then make their determination of which parts of their PKI should use or be migrated to SHA-2.
Application compatibility and preparedness should determine your SHA-2 migration plan and timing.
The use of SHA-2 signed digital certificates will become mandatory for many applications and devices in the near future. Every company with an internal PKI not already using SHA-2 will need to create a SHA-2 PKI or migrate their existing SHA-1 PKI to SHA-2
(at some point in time). A SHA-2 migration plan includes:
In most large organizations there will be some consuming application or devices which will have problems with SHA-2 digital certificates, although these instances are often a very small percentage of cases (albeit sometimes involving critical applications).
It is important that customers test every critical application and device and/or get the supporting vendor's statement on SHA-2 migrations.
Note: In the author's experience, many cases of testing showed that the consuming application or device could handle SHA-2 signed certificates, but the supporting vendor would not attest to the fitness of that application or device using SHA-2 (or recommended
a newer version to gain support). Each company will have to access its own risk if testing shows success, but the vendor will not actively support SHA-2.
Ultimately, management must be made aware of the risks associated with staying or migrating various components and make the ultimate risk decision.
Although whether or not a particular device or application implements a SHA-1 or SHA-2 signed digital certificate is an either/or decision, you can choose which components of your internal PKI (e.g. root CA, issuing CA, endpoint certificates, etc.) use SHA-1
versus SHA-2. Your entire PKI does not need to be either SHA-1 or SHA-2.
For instance, your root CA can have a SHA-1-signed CA digital certificate (without suffering a security weakness because a root trust is handled distinctly different from other PKI components), while your issuing CAs can have SHA-2 signed CA digital certificates
and issue either SHA-1 or SHA-2 signed digital certificates.
Here are the following ADCS component scenarios for implementing SHA-2 (for this example, I am assuming a 2-tier PKI (offline root, online enterprise issuing CAs) and assume all ADCS components are installed on Windows Server 2008 or later (because Windows
Server 2003 and early versions of Certificate Services cannot create SHA-2 certificates), each of which can be a new PKI component or migrated:
The rest of the options assume a single PKI tree
It is also possible to have an Issuing CA which switches back and forth between SHA-1 and SHA-2 as needed, but in ADCS this will involve a registry change and restart of ADCS services (and is not particularly recommended).
Note: Some public CAs allow you to seamlessly choose whether or not you want a SHA-1 or SHA-2 certificate, but this is seen by most experts as a temporary option. Soon, going forward, it is likely that most popular public CAs will cease to issue SHA-1 digital
The least risk, best cost answer is that you need to let your critical applications and devices determine what PKI components can be SHA-1 versus SHA-2. Many application vendors have publicly stated that as long as the evaluated endpoint certificate is SHA-2
signed, they will accept it. But at least a few vendors have stated that they will require that all certificates in the certificate path (endpoint back to root CA) be SHA-2 signed. And at least one vendor has differing and confusing public statements stating
both. If possible, during your application and device research, find out which vendors will support SHA-2 and how far in the PKI tree they will verify.
Currently, having two PKI trees, one SHA-1, one SHA-2, is probably the safest option for many organizations, but also the highest cost option. Some organizations are choosing the two tree design until they can ensure that all needed critical applications
and devices can accept SHA-2.
In many PKI consultant's experience, the most popular option for SHA-2 migrations is a SHA-1 root (often left untouched from the original design) with SHA-2 issuing CAs and endpoint certificates. Some customers are choosing SHA-1 roots, with both SHA-1 and
SHA-2 issuing CAs, and using them to accommodate whatever the consuming applications and devices need. Although this seems to work in the majority of cases, there is a risk that the customer could run into a critical device or application which verifies all
the way back to the root CA.
It is up to each PKI administrator to weigh the various risks and benefits of each deployment scenario alternative, and then make a decision.
This section discusses how to enable SHA-2 in ADCS.
Note: Each CA to be migrated from SHA-1 to SHA-2 should have its ADCS components fully backed up before migration is attempted, in case a recovery has to be made.
Whether or not SHA-1 or SHA-2 is going to be used, by default, by an ADCS CA is determined during the CA's own CA certificate's generation.
During a typical new root CA ADCS install, the cipher suite used to generate the CA's certificate and issued Certificate Revocation Lists (CRLs) is chosen on the following dialog box:
Whatever hash algorithm you choose under the
Select the hash algorithm for signing certificates used by this CA determines how the root CA's own CA certificate is signed and how it will, by default, sign other certificates and CRLs it issues.
Note: In order to see the SHA-2 family cipher options (e.g. SHA256, SHA384, SHA512, etc.), you must normally choose a KSP option under
Select a cryptographic provider. Selecting SHA256, SHA384, or SHA512 under the
Select the hash algorithm for signing certificates used by this CA essentially enables SHA-2 signing. Legacy CSPs typically do not contain the SHA-2 hash ciphers. Microsoft's CSPs definitely do not support SHA-2 ciphers, so if you use the built-in
Microsoft crypto providers you must use a Microsoft KSP to get SHA-2 support.
The CSP/KSP provider and hash selected during install are written under the following registry key:
The hash algorithm is written to CNGHashAlgorithm key and the CSP/KSP is written to
These keys can be changed to other values, and after the ADCS service is restarted, will impact the signature used sign future issued certificates and CRLs.
You can modify these values in the registry using regedit/regedt32, programmatically, or using the certutil.exe command
at an elevated command prompt.
To use the certutil.exe command to view the current values, use the following syntax:²
certutil -getreg ca\csp\CNGHashAlgorithm
certutil -getreg ca\csp\Provider
To use the certutil.exe command to set these values, use the following syntax:
certutil -setreg ca\csp\CNGHashAlgorithm <Hash Algorithm>
certutil -setreg ca\csp\Provider <KSP or CSP Name>
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
certutil -setreg ca\csp\Provider Microsoft Software Key Storage Provider
Note: As with all changes in this document, make sure you backup the setting before changing, and test thoroughly after the change.
Legacy Note: ProviderType (also shown in the figure above is set to 0, by default, for ADCS versions Windows Server 2008 and later. You can verify your ProviderType value by running the following command:
certutil -getreg ca\csp\ProviderType). A zero indicates that Cryptographic Next Generation (CNG) APIs are being used instead of older CAPI1 APIs (which were the default for Windows Server 2003 and earlier Certificate Services versions). If
the field is non-zero, the HashAlgorithm field value must be set to a valid CAPI1 value (for example 0x8004 is for SHA-1). SHA-2 is not possible with a CAPI1 API.
You can also view which CSP/KSP and hash the CA will use to sign issued certificates and CRLs by viewing the CA's certificate under the CA's server properties in the Certification Authority console (as shown below).
Although it might be confusing to some, the properties shown under the Cryptographic Settings are the CSP/KSP and hash the CA will use to sign other issued certificates and CRLs, not what the CA certificate, itself, is signed with. As previously
discussed above, you can see which CSP/KSP and hashing algorithm was used to signed the CA's digital certificate, itself, by opening the digital certificate, choosing the
Details tab, and looking at the value in the Signature hash algorithm field. These two fields can contain different hashes.
The hash chosen on the root CA determines how the Subordinate CA's certificate is signed, regardless of the CSP/KSP and hash is chosen during the subordinate CA's install (and requested in the subordinate CA's
certificate request). The requested hash in the certificate request will be ignored and the values in the registry on the parent CA will prevail.
During the Subordinate CA install, the hash algorithm you select under the
Select the hash algorithm for signing certificates used by this CA determines how the certificates and CRLs
issued by the Subordinate CA are signed. These values can also be changed using the registry keys indicated above and will apply after a restart of ADCS.
To summarize, by default, the hash algorithm selected during a root CA's install will determine the hash used to sign the root CA's own certificate and all certificates and CRLs that it issues (although you can change the signing algorithm using the registry
changes after the root CA certificate is generated). Subordinate CA's own certificate will be signed by the hash indicated during the root CA's install. The certificates issued by the Subordinate CA will be signed by the hash selected during the Subordinate
CA's install. All selected ciphers used for signing issue certificates and CRLs can be changed in the registry, and after restarting ADCS, will apply to all future issued certificates and CRLs.
It's also important to note that the certificate template version or the client requesting the certificate has no impact on whether or not the CA signs with a particular hash. The hash used to sign digital certificates is determined by the fields and values
In every certificate template (version 2 and later), there is a Cryptography tab (see below) on Windows Server 2008 ADCS (and later). Some people mistakenly believe that the hash selected here will dictate which hash is used to sign the certificates resulting
from the template. This is not correct. This setting dictates which hash types can be used for a certificate request and
sign the certificate request. In any case, currently ADCS will accept a request in any recognized hash and format, and the resulting issued certificate's hash is dictated by the hash selections previously identified
above (and is not directed by any setting in the template).
To keep and existing CA certificate and private key, but convert it from CSP/SHA-1 to KSP/SHA-2, follow the instructions here:
Some applications supporting SHA-2 have problems with the larger SHA-2 key sizes, such as SHA-512.
Here are some relevant links:
Because of cryptographic weaknesses in the SHA-1 hash, it is likely that SHA-2 signed certificates will be required in the near future for both public and private CAs. This document covers how to plan and configure SHA-2 in an enterprise Active Directory