Implementing SHA-2 in Active Directory Certificate Services

Microsoft IT

Information Security and Risk Management

 

By Roger A. Grimes, ISRM ACE Team, Principal Security Architect, rogrim@microsoft.com

Published: 6/15/15

v.1.0 

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

Change Record

Date	Author	Version	Change Reference
6-15-15	Roger A. Grimes	1.0	Initial version

 

↑ Return to Top

Reviewers

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

 

↑ Return to Top

Contents

 

↑ Return to Top

Download

Download an offline copy of this article at the TechNet Gallery: https://aka.ms/sha2

 

↑ Return to Top

Introduction

 

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 https://technet.microsoft.com/en-us/library/dn771627.aspx.

 

↑ Return to Top

Cryptographic Hashes in General

This section will discuss the importance of cryptographic hashes and the SHA family of hashes in particular.

 

↑ Return to Top

What is a Hash and Why Are They Important?

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 message output). 

A good hash has many important cryptographic properties, including:

• Whenever the same content is inputted, the same hash output is always generated
• Whenever different content is inputted, a different hash output is always generated
• No two different inputs should ever create the same output (otherwise known as a collision or second preimage attack)
• It should be non-trivial for anyone to determine the original input by analyzing the hash output alone (a successful attack doing this is known as a preimage attack)

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. 

↑ Return to Top

CSP vs. KSP?

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. 

↑ Return to Top

Verifying Hash Signature Used on Digital Certificate or CRL

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: 

Signature Algorithm:

    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA

    Algorithm Parameters:

Public Key Algorithm:

    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)

    Algorithm Parameters:

Signature Algorithm:

    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA

    Algorithm Parameters: 

↑ Return to Top

Viewing Hash Signature of Digital Certificate

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. 

↑ Return to Top

Verifying Hash Used By CA To Sign Newly Issued Digital Certificates and CRLs

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.

↑ Return to Top

How Can A Hash Be Vulnerable?

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 2⁵⁰ 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.

↑ Return to Top

What are SHA-1 and SHA-2?

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 2⁸⁰ tries to find a hash collision. Even in today's world of very fast and a multitude of cloud computers, 2⁸⁰ 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).

↑ Return to Top

SHA Attacks

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.

↑ Return to Top

Why You Need SHA-2

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/).

↑ Return to Top

Microsoft's SHA-1 Deprecation Policy

Microsoft announced our stance on SHA-1 in multiple blog articles, including

• http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx,
• http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx, and
• https://technet.microsoft.com/en-us/library/security/2880823.aspx 

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.

↑ Return to Top

Microsoft OS SHA-2 Support

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.

↑ Return to Top

Microsoft Outlook Support

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. 

See http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx for more detailed information and recommendations. 

↑ Return to Top

Other Microsoft Application SHA-2 Support

Here is the list of supported or non-supported SHA-2 Microsoft applications collected so far by this author.

• Web enrollment website - supports SHA-2, but only using v2 templates
• Smartcards (PKINIT) - supported
• KDC certificates used for Domain Controller authentication and Kerberos - supported
• Kerberos Ticket Granting Tickets (TGTs) and Service Tickets - not supported, but unrelated to certificates anyway
• Configuration Manager - supported for most scenarios but not for:  Out of band service point, Site system when running Intune connector, Mobile device clients, and Intel AMT-based computers. Please refer to: https://technet.microsoft.com/en-us/library/gg699362.aspx
• FIM-CM - not supported for signing
• NDES/SCEP - an NDES server is only able to use its own signing and encryption keys via legacy CSP APIs (CAPI1 APIs), which means that the NDES server itself cannot use SHA2 hash algorithms for signing its SCEP responses, but SCEP clients can still obtain certificates through the NDES server from ADCS that are signed with SHA2
• TLS 1.2 supports SHA-256 and SHA-384, but not SHA-512
• Microsoft's built-in crypto APIs do not support SHA-192
• Visual Studio - Programs and other content published/re-published using Visual Studio 2013 Update 3 or newer can support SHA-2

↑ Return to Top

Microsoft Code Signing SHA Support

This table describes which hash algorithms are supported for code signing for the following files formats and Windows versions:

File Format	Windows 8/8.1 Windows Server 2012 RTM/R2	Windows 7 Windows Server 2008 R2	Windows Vista Windows Server 2008
Portable Executable (PE) (.exe, .dll, .mui, .)	SHA1, SHA256, SHA384, SHA512 Multiple Signatures Supported	SHA1, SHA256 SHA384, SHA512	SHA1
Cabinet (.CAB)	SHA1, SHA256, SHA384, SHA512 Multiple Signatures Supported	SHA1, SHA256, SHA384, SHA512	SHA1
Authenticode Catalog (.cat)	SHA1, SHA256	SHA1	SHA1
Jscript / .VBS/ .WSF	SHA1, SHA256, SHA384, SHA512	SHA1, SHA256, SHA384, SHA512	SHA1
PowerShell	SHA1, SHA256, SHA384, SHA512	SHA1, SHA256, SHA384, SHA512	SHA1
Windows Installer (.MSI, MSP)	SHA1, SHA256, SHA384, SHA512	SHA1, SHA256, SHA384, SHA512	SHA1
.AppX	SHA1, SHA256, SHA384, SHA512	N/A	N/A

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.

↑ Return to Top

ClickOnce Manifests

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.

File Format	.NET 4.5	.NET 4.0	.NET 3.5 and below
.NET ClickOnce Manifest	SHA1, SHA256, SHA384, SHA512	SHA1, SHA256	SHA1

Note: Timestamp support is limited to SHA1.

↑ Return to Top

Other Major Vendor SHA-2 Support Statements

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.

• Mozilla Firefox - https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
• Google - http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
• Facebook apps will have to support SHA-2 as of October 1, 2015 (https://threatpost.com/facebook-requires-sha-2-as-of-oct-1/113131)

Every OS and application vendor could have a different deprecation plan. Check with your browser of choice vendor for more details. Because of this deprecation pressure, it's expected that most public Certification Authorities (CAs), will no longer issue SHA-1 based certificates with useful lives beyond 1/1/2017. Everything after that will be SHA-2.  If you've currently got a public-facing server or site with a SHA-1 certificate, you'll want to upgrade it to SHA-2, especially before 1/1/17. 

↑ Return to Top

The Problem and Migration Planning

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.

↑ Return to Top

SHA-2 Migration Plan

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:

1. Educating involved team members about what SHA-2 is and why its use is being mandated (this document is a good start)
2. Inventory of all critical hash/digital certificate consuming or using applications and devices
3. Determination of which critical consuming applications or devices can use SHA-2, and what key sizes, which cannot, and what the operational concerns may be (this often includes contacting the vendor and testing)
4. Determination of which PKI components can or will be migrated to SHA-2
5. Create migration plan to convert SHA-1 components to SHA-2, including consuming clients and PKI components, plus fallback plan in case of critical failure
6. Proof of concept testing
7. Management risk acceptance and go/no-go decision
8. Implementation of migration plan in production environment
9. Testing and Feedback

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.

↑ Return to Top

Where Can SHA2 Be Implemented in ADCS?

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: 

• Two PKI trees, one all SHA-1, one all SHA-2 

The rest of the options assume a single PKI tree

• Entire PKI tree, from root to endpoints, are all SHA-1
• Entire PKI tree, from root to endpoints, are all SHA-2
• SHA-1 root, SHA2 issuing CAs, SHA2 endpoint certificates
• SHA-1 root, SHA2 issuing CAs, SHA1 endpoint certificates
• SHA-1 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates
• SHA-2 root, SHA-1 issuing CAs, SHA-1 endpoint certificates
• SHA-2 root, SHA-2 issuing CAs, SHA-1 endpoint certificates
• SHA-2 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates

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 certificates.

↑ Return to Top

Where Should You Implement SHA2?

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.

↑ Return to Top

Implementing SHA-2 in ADCS

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.

↑ Return to Top

Configuring Root CAs for SHA-2

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: 

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAname]\CSP 

 

The hash algorithm is written to CNGHashAlgorithm key and the CSP/KSP is written to Provider key. 

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

For example: 

                    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.

↑ Return to Top

Configuring Subordinate CAs for SHA-2

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 listed above.

↑ Return to Top

Request Signing Confusion

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).

 

 

↑ Return to Top

Miscellaneous ADCS SHA-2 Facts

To keep and existing CA certificate and private key, but convert it from CSP/SHA-1 to KSP/SHA-2, follow the instructions here: https://technet.microsoft.com/en-us/library/dn771627.aspx.

• It should be noted that conversion requires a Windows Server 2012 certutil.exe, as Windows Server 2008 (and prior) do not support the necessary KSP conversion commands. If you want to convert a CA certificate on an ADCS version prior to Windows Server 2012, you must export the CA cert off of the CA, import onto ADCS 2012 or later using certutil.exe with the -KSP option, then export the newly signed certificate as a PFX file, and re-import on the original server.
• If an HSM or non-Microsoft CSP/KSP is involved, the PFX conversion steps at this link will have to be replaced by vendor-specific CSP to KSP key migration.

Some applications supporting SHA-2 have problems with the larger SHA-2 key sizes, such as SHA-512.

Here are some relevant links:

• https://social.technet.microsoft.com/Forums/en-US/b6ffa278-4a04-4609-ac35-8390f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls-12-not-working?forum=winserversecurity,
• http://www.michaelm.info/blog/?p=1273, http://ucken.blogspot.ca/2013/12/schannel-errors-on-lync-server.html, and
• http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx

 

↑ Return to Top

Other Related Reading

• Articles and tools related to hash collisions: https://marc-stevens.nl/research/ 

↑ Return to Top

Conclusion

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 Service Services.

↑ Return to Top