Implementing SHA-2 in Active Directory Certificate Services (ADCS)

Transcription

1 Implementing SHA-2 in Active Directory Certificate Services (ADCS) Microsoft IT Information Security and Risk Management By Roger A. Grimes, ISRM ACE Team, Principal Security Architect, Published: 11/17/15 v.1.14

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

3 Revision Sheet Change Record Date Author Version Change Reference Roger A. Grimes 1.0 Initial version Roger A. Grimes 1.01 Fixed a single typo Roger A. Grimes 1.02 Updated minor content issues from reviewers Roger A. Grimes 1.03 Continue to update and refine content Roger A. Grimes 1.1 Updated with Microsoft s latest SHA-1 treatment policy Roger A. Grimes 1.11 Clarified Code-signing certificate treatment Roger A. Grimes 1.12 Clarified that SubCAs should be signed by SHA-2 when SHA-1 is depreciated Roger A. Grimes 1.13 Added minor updates Roger A. Grimes 1.14 Added CRL treatment clarification 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 Noam Ben-Yochanan, Senior Program Manager, Microsoft Certificate Services Discussion List, Microsoft

4 Contents Reviewers... 3 Introduction... 5 Cryptographic Hashes in General... 5 What is a Hash and Why Are They Important?... 5 CSP vs. KSP?... 5 Verifying Hash Signature Used on Digital Certificate or CRL... 6 Viewing Hash Signature of Digital Certificate... 8 Verifying Hash Used By CA To Sign Newly Issued Digital Certificates and CRLs... 8 How Can A Hash Be Vulnerable?... 9 What are SHA-1 and SHA-2?... 9 SHA Attacks Why You Need SHA Microsoft's SHA-1 Deprecation Policy Microsoft OS SHA-2 Support Microsoft Outlook Support Other Microsoft Application SHA-2 Support Microsoft Code Signing SHA Support ClickOnce Manifests Other Major Vendor SHA-2 Support Statements The Problem and Migration Planning SHA-2 Migration Plan Where Can SHA2 Be Implemented in ADCS? Where Should You Implement SHA2? Implementing SHA-2 in ADCS Configuring Root CAs for SHA Configuring Subordinate CAs for SHA Request Signing Confusion Miscellaneous ADCS SHA-2 Facts Other Related Reading Conclusion... 23

5 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 Cryptographic Hashes in General This section will discuss the importance of cryptographic hashes and the SHA family of hashes in particular. 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 (as is feasibly possible given that inputs are infinite and hash outputs are finite) 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. 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

6 (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. Viewing Hash Signature of a File A great way to view file hash signatures is using Microsoft's free utility, Sigcheck ( Use the command-line utility, Sigcheck with the -h parameter to show the file hashes. See example below. Sigcheck shows several hashes including MD5, SHA1, and SHA256. PESHA1 and PE256 are the SHA1 and SHA2 equivalents for Microsoft Authenticode signatures, which only hashes the "content" areas of a PE file, and does not include PE header or "filler" information. For non-pe files, the SHA1/SHA256 and PESHA1/PE256 hashes will the same. Some Microsoft applications and features, like AppLocker's file hash rules use the PE256 hashes instead of SHA256. 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).

7 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: sha256rsa Algorithm Parameters: Public Key Algorithm: Algorithm ObjectId: RSA (RSA_SIGN) Algorithm Parameters: Signature Algorithm:

8 Algorithm ObjectId: sha256rsa Algorithm Parameters: 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 you can run many different utilities, including sigcheck.exe (covered above) and the builtin certutil.exe command-line utility. To use either command-line utility, you'll first need to export the digital certificate to a file and then run the command-line utility on the physical file. Here's an example syntax of using certutil.exe: 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): c 4e a d Cert Hash(sha1): 9f 94 c4 d4 8f 43 d8 bf 7a a d8 7b 3d 0f 95 e3 c4 7d Cert Hash(sha256): acbc8cd3c4886bbe1dd142127ba6b5c22219e03e a67d447b20174 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 integrity of the object. Verifying Hash Used By CA To Sign Newly Issued Digital Certificates and CRLs ADCS CA's can only sign with a single CSP/KSP and hash algorithm at one time. Whatever CSP/KSP and hash algorithm is current defined is what the CA will use to sign all issued digital certificates and CRLs, until those values are changed. 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,

9 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 applications. Other applications may contain their own code. When determining where or whether hash verification is done, each specific scenario must be analyzed. 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 50 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. 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 SHA-1 produces a 160-bit message digest, which if cryptographically secure, means that it would take a brute force guessing attack 2 80 tries to find a hash collision. Even in today's world of very fast and multitude of cloud computers, 2 80 tries is considered non-trivial to create a useful attack. In January 2011 (with publication of National Institute of Standards and Technology (NIST) document SP A), 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).

10 SHA Attacks Starting in 2005, several theoretical attacks against SHA-1 have been publically documented. By 2012, SHA-1 attacks ( have theoretically reduced SHA-1's protection from 80-bit maximum average to 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). 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. Note: Here is a good example of a useful MD-5 collision: 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 ( Because attacks have been demonstrated against both SHA-1 and SHA-2, NIST is has already selected the next recommended hash standard ( called 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. 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 venders, including operating system and browser vendors, are now actively working to eliminate reliance on SHA-1 and replace it with SHA-2. Much of the SHA-1 deprecation effort is being driven by a consortium of vendors, which are part of the CA/Brower Forum ( which includes Microsoft, Google, and many other popular software vendors. In general, most vendors should be following the SHA-1 deprecation settings declared

11 in the formal the CA/Browser Forum Baseline Requirements document ( 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 vendor 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 ( Microsoft's SHA-1 Deprecation Policy Microsoft announced our initial stance on SHA-1 in multiple blog articles (since updated), including and The most current Microsoft policy statement this author is aware of is posted (on 9/24/15) at: which currently links to: Here is a summary of the treatment of SHA-1 signed certificates by Windows (only) as of 10/28/15: The policy applies to supported versions of Windows (i.e. Windows Vista and Windows Server 2008 and later), and only for certificates issued by CAs in Microsoft's Windows Root Certification program ( This means any certificate issued by a CA not in Microsoft s Windows Root Certification program is not evaluated for SHA-1 versus SHA-2 signing. Note: SHA-1 deprecation enforcement will be applied using a new software update, which has not yet been made available or pushed (as of 10/28/15). There are separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates. SSL/TLS Certificates SSL/TLS certificates signed by SHA-1 signatures will not be trusted after 1/1/17. CAs in the Microsoft Windows Root Certification program must stop issuing new SHA1-signed SSL end-entity certificates by 1/1/16. This means any time valid SHA-11 SSL/TLS certificates must be replaced with a SHA-2 equivalent by 1/1/17.

12 Code Signing Certificates Windows will trust a file signed with a SHA-1 code signing certificate if it is timestamped prior to 1/1/16. If a file is signed with a SHA-1 code signing certificate is not timestamped before 1/1/16, it will be untrusted as of 1/1/17. This enforcement will be performed only in user mode using the framework that Windows has for blocking weak cryptographic algorithms. Code signed and timestamped with SHA-1 certificates before January 1, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to preimage attack. Note: Microsoft software does not have built-in timestamping functionality, but various Microsoft signing tools, like Signtool.exe ( are able to timestamp signed code if provided with a timestamp source. 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 10/1/2015) SHA-1 deprecation policies does not apply. CAs in the Windows Root Certification Program must stop issuing SHA-1 certificates as of 1/1/16. Microsoft's treatment of SHA-1 and its further deprecation will be discussed more at the appropriate future time. Microsoft Legacy 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 KB ( 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.

13 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 SHA-2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate 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 SHA-2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA-2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed. See for more detailed information and recommendations. 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 web site - 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 - not supported FIM-CM - not supported for signing NDES/SCEP Microsoft s ADCS NDES service role can issue SHA-2 signed certificates to requesters, but its signing and encryption certificates that it uses, itself, to provide a secure channel to requesters can only be SHA-1 signed. 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 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, ) Cabinet (.CAB) SHA1, SHA256, SHA384, SHA512 Multiple Signatures Supported SHA1, SHA256, SHA384, SHA512 SHA1, SHA256 SHA384, SHA512 SHA1, SHA256, SHA384, SHA512 SHA1 SHA1

14 Multiple Signatures Supported Authenticode Catalog (.cat) SHA1, SHA256 SHA1 SHA1 Jscript /.VBS/.WSF SHA1, SHA256, SHA1, SHA256, SHA1 SHA384, SHA512 SHA384, SHA512 PowerShell SHA1, SHA256, SHA1, SHA256, SHA1 SHA384, SHA512 SHA384, SHA512 Windows Installer (.MSI, MSP) SHA1, SHA256, SHA1, SHA256, SHA1 SHA384, SHA512 SHA384, SHA512.AppX SHA1, SHA256, N/A N/A SHA384, SHA512 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 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 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 SHA1, SHA256, SHA1, SHA256 SHA1 Manifest SHA384, SHA512 Note: Timestamp support is limited to SHA1. Other Major Vendor SHA-2 Support Statements In general, most vendors should be following the SHA-1 deprecation settings declared by the CA/Browser Forum ( which states SHA-1 deprecation dates for 1/1/16 and 1/1/17. Further the forum states that all SHA-2 end-entity certificates should be chained back to a SHA-2 issuing CA (section 7.1.3). This is a small list of major vendors and their stated SHA-2 support statements. Check with each vendor's web site to get a list of the current support statements. Mozilla Firefox - certificates/ Google - 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.

15 Facebook apps will have to support SHA-2 as of October 1, 2015 ( CRL SHA-1 Deprecation Treatment The CA/Browser Forum does not discuss Certificate Revocation List (CRL) deprecation treatment, so it is assumed that most vendors will not be checking to see if CRLs are signed by SHA-1 or SHA-2, although that could change in the future. Currently, Microsoft does not have plans to test CRLs for SHA-1 deprecation purposes. This means that CRLs can be signed by SHA-1 or SHA-2 signatures without impacting operations. 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. 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 it's 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

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

17 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. 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. The CA/Browser forum, which is somewhat authoritative on SHA-1 depreciation states that all SHA-2 signed end-entity certificates should chain back to a SHA-2 issuing CA, although SHA-1 signed root CAs are still allowed ( Applications following the CA/browser forums recommendations will not care if the root CA is SHA-1 or SHA-2, but of course root CAs should be upgraded to SHA-2 upon the next needed root CA certificate renewal. Many application vendors have publicly stated that as long as the evaluated endpoint certificate is SHA- 2 signed, they will accept it. 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. But in general, because of the CA/Browser forum recommendations, having the issuing CA(s) and all related end-entity certificates be in sync is the safest deployment option. 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. 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. 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:

18 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

19 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: For example: 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).

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

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

22 Mixed SHA-1 and SHA-2 Deployments Many customers may decide to have both SHA-1 and SHA-2 issuing CAs signed up to a single root CA. The root CA s own CA certificate can usually be either SHA-1 or SHA-2 signed and not impact the rest of the trust chain. But in order for a single PKI trust chain to support both SHA-1 and SHA-2 issuing CAs at the same time, the root CA s signing key will have to be switched back and forth as needed when signing the underlying issuing CAs. The process will look something like this: 1. When a SHA-1 signed issuing CA is needed: a. Make sure root CA is configured to use SHA-1 signing (using regedits noted above, if needed and not already done, and restart the ADCS service) b. Sign issuing CA cert with SHA-1 c. Publish and distribute SHA-1 signed CRL i. You may need to change CDP pathways prior to publishing the CRL to direct SHA-1 consuming clients to a SHA-1 signed CRL. 2. When a SHA-2 signed issuing CA is needed:

23 a. Make sure root CA is configured to use SHA-2 signing (using regedits noted above, if needed and not already done, and restart the ADCS service) b. Sign issuing CA cert with SHA-2 c. Publish and distribute SHA-2 signed CRL i. You may need to change CDP pathways prior to publishing the CRL to direct SHA-2 consuming clients to a SHA-2 signed CRL. 3. Convert the root CA between SHA-1 and SHA-2 and issue CRLs as needed Note: When a CRL is published by ADCS, it will use the signing algorithm currently in effect. However, since CRLs will normally contain the same CDP pathways regardless of whether being SHA-1 or SHA-2 signed, it may be necessary for admins to modify the CDP pathways to point to distinct SHA-1 and/or SHA-2 signed CRL versions for their respective consuming clients, prior to generating and distributing CRLs. The CA/Browser Forum SHA-1 deprecation requirements does not specifically discuss the recommended treatment of SHA-1 signed CRLs, so it is up to each customer to decide on what CRL version(s) they want to run if running a split PKI as described in this section. Miscellaneous ADCS SHA-2 Facts To keep an existing CA certificate and private key, but convert it from CSP/SHA-1 to KSP/SHA-2, follow the instructions here: o 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. o 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: US/b6ffa278-4a ac f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls- 12-not-working?forum=winserversecurity, and Other Related Reading NIST SHA-3 Standard: Articles and tools related to hash collisions: 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.