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, rogrim@microsoft.com Published: March 30, 2017 v.4.02 Latest version of this paper can be found at http://aka.ms/sha2

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.

© 2017 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.

Revision Sheet

Change Record

Date Author Version Change Reference

6-15-15 Roger A. Grimes 1.0 Initial version

6-16-15 Roger A. Grimes 1.01 Fixed a single typo

6-17-15 Roger A. Grimes 1.02 Updated minor content issues from reviewers

7-10-15 Roger A. Grimes 1.03 Continue to update and refine content

10-1-15 Roger A. Grimes 1.1 Updated with Microsoft’s latest SHA-1 treatment

policy

10-1-15 Roger A. Grimes 1.11 Clarified Code-signing certificate treatment

10-26-15 Roger A. Grimes 1.12 Clarified that SubCAs should be signed by SHA-2

when SHA-1 is depreciated.

10-28-15 Roger A. Grimes 1.13 Added minor updates

11-17-15 Roger A. Grimes 1.14 Added CRL treatment clarification

1-5-16 Roger A. Grimes 1.15 Minor additions

1-6-16 Roger A. Grimes 1.16 Update: Included information on user experience

when handling impacted SHA-1 signed certificates

when enforcement is enabled

Update: Included registry key edits that can

disable SHA-1 deprecation in Windows when

Microsoft Windows SHA-1 deprecation

enforcement gets applied

Corrections: Corrected previous mistake which

said that apps written using CAPI or CAPI1 could

not use SHA-2 signed certificates, and corrected

that ADFS can use SHA-2.

1-22-16 Roger A. Grimes 1.17 Correction: Updated NDES section to say that

NDES does support SHA-2. Previous versions

incorrectly said it did not.

2-1-16 Roger A. Grimes 1.18 Added: Section on SHA-1 password cracking

2-2-16 Roger A. Grimes 1.19 Added: Note on needed patch for Windows 7 and

Server 2008 R2 for code signing

Date Author Version Change Reference

2-3-16 Roger A. Grimes 1.20 Corrected: Corrected code signing untrusted date

from Jan. 1, 2017 to Jan. 1, 2016

Updated: Added patch support option for SHA-

512 for TLS 1.2

2-3-16 Roger A. Grimes 1.21 Added: Added link to related PPT summary

2-23-16 Roger A. Grimes 1.22 Minor updates

Correction: Corrected document to confirm that

Configuration Manager does support SHA-2.

3-8-16 Roger A. Grimes 1.23 Correction: Corrected document to confirm that

FIM-CM does support SHA-2

4-27-16 Roger A. Grimes 1.25 Several changes:

• Add substantial CSP to KSP migration

instructions

• Updated Microsoft’s SHA-1 deprecation

date to Feb. 14, 2017

4-27-16 Roger A. Grimes 1.26 • Clarified/improved several sections

• Added CA renewal section

• Added certificate request SHA-2 signing

section

• Added notes on OCSP considerations

after renewing CA certificate

5-17-16 Roger A. Grimes 1.28 • Added new section on Windows 10

Anniversary Update SHA-1 deprecation

enforcement

• Minor updates

5-17-16 Roger A. Grimes 1.29 More clarification on Microsoft’s SHA-1

Deprecation enforcement policies

7-25-16 Roger A. Grimes 2.0 Some moderate updating

10-23-16 Roger A. Grimes 2.01 • Added section detailing commands which

allow early SHA-1 depreciation testing

• Corrected maximum SHA-1 protection to 159-

bits of protection versus my incorrect prior

statement of 80-bits (thanks to readers)

11-5-16 Roger A. Grimes 3.0 Make Microsoft SHA-1 deprecation policy update.

Only impacts TLS certs now.

Date Author Version Change Reference

2-23-17 Roger A. Grimes 4.0 Updated to reflect complete SHA-1 cryptographic

break and Microsoft’s updated policy.

3-17-17 Roger A. Grimes 4.01 Further clarification of Microsoft’s current SHA-1

deprecation policy

3-30-17 Roger A. Grimes 4.02 Added pretty graphic summarizing Microsoft’s

current SHA-1 depreciation policy

Note: This whitepaper reflects the best understanding of the author and can be relied upon as official

Microsoft information. Even though the author and reviewers have strived to produce the most

accurate document possible it may contain errors or current information may be changed or updated in

future versions.

Reviewers The following Microsoft employees have reviewed at least one version of this document and made

recommendations that are included in one or more versions. Reviewers include:

Mark Wilson, Senior Premier Field Engineer, Microsoft

Dale Vincent, Microsoft Premier Field Engineer

Fernando Goncalves, Microsoft Premier Field Engineer

Noam Ben-Yochanan, Senior Program Manager, Microsoft

Certificate Services Discussion List, Microsoft

Contributors Jason Jones, Principal Consultant, Microsoft Sanjay Pillai, Senior Operations Program Manager, Microsoft Jody Cloutier, Senior Security Program Manager, Microsoft

Contents Reviewers ...................................................................................................................................................... 5

Contributors .................................................................................................................................................. 5

Introduction .................................................................................................................................................. 8

Cryptographic Hashes in General .................................................................................................................. 8

What is a Hash and Why Are They Important? ......................................................................................... 8

CSP vs. KSP? .......................................................................................................................................... 9

Viewing Hash Signature of a File ........................................................................................................... 9

Verifying Hash Signature Used on Digital Certificate or CRL .............................................................. 14

Using Certutil to Identify the Certificate Signature Algorithm ........................................................... 16

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

How Can a Hash Be Vulnerable? ............................................................................................................. 17

What are SHA-1 and SHA-2? ................................................................................................................... 18

SHA Attacks ............................................................................................................................................. 18

Why You Need SHA-2 .............................................................................................................................. 20

Microsoft's SHA-1 Deprecation Policy ........................................................................................................ 21

TLS Certificates ........................................................................................................................................ 22

Other Certificates .................................................................................................................................... 23

SHA-1 Depreciation Enforcement ........................................................................................................... 23

Logging SHA-1 Certificates .................................................................................................................. 24

Disabling Microsoft Windows SHA-1 Deprecation Enforcement ........................................................ 24

Enabling Early Enforcement of SHA-1 Enforcement for Testing Purposes ......................................... 24

Microsoft Legacy OS SHA-2 Support ....................................................................................................... 25

Microsoft Outlook Support ................................................................................................................. 26

Other Microsoft Application SHA-2 Support ....................................................................................... 26

Microsoft Code Signing SHA Support .................................................................................................. 27

ClickOnce Manifests ............................................................................................................................ 27

Other Major Vendor SHA-2 Support Statements ............................................................................... 28

CRL SHA-1 Deprecation Treatment ..................................................................................................... 28

The Problem and Migration Planning ......................................................................................................... 28

SHA-2 Migration Plan .............................................................................................................................. 29

Where Can SHA2 Be Implemented in ADCS? .......................................................................................... 29

Where Should You Implement SHA2? .................................................................................................... 30

Implementing SHA-2 in ADCS ..................................................................................................................... 31

Configuring New Root CAs for SHA-2 ...................................................................................................... 31

Configuring New Subordinate CAs for SHA-2 ......................................................................................... 33

Migrating Existing ADCS CA from SHA-1 CSP to SHA-2 KSP .................................................................... 34

Converting Existing KSP SHA-1 CA to SHA-2 ........................................................................................... 38

Renewing a Child CA Certificate with an Offline Parent CA ................................................................ 39

Don’t Forget To Update OCSP After Updating the CA Certificate ...................................................... 41

Mixed SHA-1 and SHA-2 Deployments ................................................................................................... 41

Certificate Request Information ................................................................................................................. 42

Creating SHA-2 Certificate Requests ....................................................................................................... 42

Request Signing Confusion and Certificate Templates ........................................................................... 42

Miscellaneous ADCS SHA-2 Facts ............................................................................................................ 43

Other Related Reading ................................................................................................................................ 43

Conclusion ................................................................................................................................................... 44

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 articles

http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-

authenticode-code-signing-and-timestamping.aspx and https://technet.microsoft.com/en-

us/library/dn771627.aspx.

A related PowerPoint slide summary (in PDF format) can be found here:

https://gallery.technet.microsoft.com/Introduction-to-SHA-2-1ffcda11.

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/CAPI1 has not been updated since Windows XP/Windows Server 2003 and there is limited support for new ciphers, like SHA-2 and ECC, but it is still included in Windows (for now) for backwards compatibility purposes. At least one Microsoft CSP (Microsoft Enhanced RSA and AES Cryptographic Provider) provides support for SHA-2 hash signing algorithms. This means that a CAPI/CAPI1-programmed application may or may not support SHA-2, and its support should be verified. Correction Note (Jan. 6, 2016): Previous versions of this document incorrectly stated that CAPI/CAPI1

applications could not support SHA-2.

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/CAPI1 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. An application using CAPI2 should be capable of supporting SHA-2. In summary, 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 CAPI/CAPI1, that application may not 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 built-in File Explorer. Right-click the file, choose Properties, and then look for the Digital Signatures tab. If the Digital Signatures tab is not shown the file is not signed or is signed in a way Windows cannot automatically enumerate. See examples below.

Example File Without Digital Signature

Example File With SHA-1 Signature

Example File With SHA-256 Signature

Example File Dual Signed With SHA-1 and SHA-256

Using Signtool.exe To Verify Signed File Hashes The free Windows Software Development Kit for Windows 10 (https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk), and other versions of the Windows SDK, contains a useful utility called signtool.exe. It can be used to display the signature algorithm and hash of a signed file. The syntax is: signtool.exe verify /pa /all [filename] An example is shown below. You can add a /verify switch to see the hash outputs themselves.

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 the 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. See example of thumbprint below.

Using Certutil to Identify the Certificate Signature Algorithm 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 the built-in 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: 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:

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

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 2159 tries to find a hash collision, on average (over infinity of tries). Even in today's world of very fast and multitude of cloud computers, 2159 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).

SHA Attacks Starting in 2005, several theoretical attacks against SHA-1 have been publicly documented. By 2012, SHA-1 attacks (http://en.wikipedia.org/wiki/SHA-1#Attacks) have theoretically reduced SHA-1's protection from 159-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). 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. On February 23, 2017, Google announced (https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html) a successful SHA-1 collision attack, demonstrated by presented two different PDF files with the same SHA-1 hash. This attack essentially “breaks” SHA-1 completely, and it should no longer be relied upon. Here’s the example PDF collision using SHA-1 announced on February 23, 2017, on http://shattered.io.

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. In 2012, the Flame malware worm used a “broken” MD-5 signed Microsoft certificate to make it appear as if the malware was code signed by Microsoft (http://arstechnica.com/security/2012/06/flame-malware-hijacks-windows-update-to-propogate/). The digital signature is shown below:

Microsoft had stopped using the MD-5 signed certificate many years ago, but it had not been revoked, and the malware writers were able to exploit the mistake. Upon discovery, Microsoft revoked the

involved certificate and made sure there were no other still valid MD-5 Microsoft certificates in the public domain. 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). Note: There are several tools and services which will crack SHA-1 password hashes back to their original plaintext equivalents fairly quickly (hours to a few days). This is possible because the original passwords are fairly short and non-complex (as compared to other signed content), and doesn’t really apply to the attacks which would be applied to digital signing. Because attacks have been demonstrated against both SHA-1 and SHA-2, NIST is has already selected the next recommended hash standard (http://www.nist.gov/itl/csd/201508_sha3.cfm) 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.

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 (https://cabforum.org/), which includes Microsoft, Google, and many other popular software vendors. In general, most vendors should be following the SHA-1 deprecation settings declared in the formal the CA/Browser Forum Baseline Requirements document (https://cabforum.org/wp-

content/uploads/Baseline_Requirements_V1_3_1.pdf). Note: The CA/Browser Forum’s SHA-1 depreciation guidelines only refer to “public” TLS certificates, but many vendors have extended the guidelines to other types of certificates and some vendors make no distinction between public and private PKIs. 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 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's SHA-1 Deprecation Policy This section of the paper covers Microsoft’s SHA-1 deprecation policy and treatment in Microsoft Windows and other Microsoft applications. The most current Microsoft policy statement is posted at: http://aka.ms/sha1, which currently links to: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx. There are 3 phases:

▪ Phase 1 - Took Effect in Summer 2016 ▪ “TLS lock icon” will not appear on “public” SHA-1 signed TLS certificates in IE/Edge,

making it look like TLS connection is not established, even though TLS connection may be established

▪ Phase 2 - Planned to take effect in mid-2017 ▪ IE/Edge will present warning message for SHA-1 signed TLS certificates in IE/Edge

▪ Phase 3 - Not date yet announced ▪ Behavior not announced, but expected to be further rejection of SHA-1 signed

certificates (and possibly more)

Graphic taken from: https://blogs.technet.microsoft.com/yurikasensei/2016/11/29/sha1-users-guide/

Here is a summary of the treatment of SHA-1 signed certificates by Microsoft Windows and Microsoft

browsers (only) as of November 5, 2016: Only “public” (end-entity certificates chained to a root CA

enrolled in the Microsoft Trusted Root Program) TLS certificates (a cert containing the Server

Authentication OID) will be evaluated.

Note1: Other vendors may not make the distinction about the public versus private part so their

software may also have issues with private TLS certs as well.

In Phase 1, if an impacted HTTPS certificate is used by Edge or IE, the “lock icon” will not be shown, even

if a TLS connection is established. In Phase 2, mid-2017, the SHA-1 certificate will be considered invalid,

cause a message warning in IE/Edge, but can be bypassed to access the HTTPS web page. In both

instances, if the SHA-1 certificate is used and providing any protection, that protection is not removed.

Phase 3, no date(s) or enforcement behaviors are currently set. Microsoft intends to completely disable

SHA-1 hashes and signing across all Microsoft products and will likely apply to both private and public

certificates.

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

TLS Certificates CAs in the Microsoft Windows Root Certification program must stop issuing new SHA1-signed TLS end-entity certificates by Jan. 1, 2016. When Microsoft software comes across SHA-1 TLS certificates, the certificate will be considered untrusted, and handled accordingly. Currently this means, in Microsoft Edge/Internet Explorer 11, the TLS-protected web site will not have the “lock icon” display and a warning message will be displayed. The currently implemented TLS protections will still be in place and the user can click around the warning message and load the web site. Starting in June and July of 2016, Microsoft made available recommended updates for Windows 7 (and later), which if applied, would remove the lock icon on web sites with public SHA-1 signed TLS certificates, with no other warning. The currently implemented TLS protections will still be in place and the user will have already loaded the web page. The relevant KBs are:

Here is an example of Internet Explorer 11 connecting to an example affected web site prior to these updates being applied (notice the presence of the lock icon and no warnings):

Here is an example of Internet Explorer 11 connecting to the same example affected web site after the update is applied (note an absence of the lock icon despite the https: moniker):

In Phase 2, mid-2017, Microsoft browsers will also include a warning notice in addition to the “missing” lock icon. Users will be able to bypass the warning and load the web site. Note: Although many in the industry refer to “SSL Certificates” when speaking inclusively about certificates used in HTTPS, SSL is a discontinued vulnerable protocol, now replaced by TLS. The term SSL should be replaced by TLS when discussing HTTPS communications.

Other Certificates Microsoft reserves the right to modify its SHA-1 depreciation policies at any time, especially as

additional SHA-1 attacks become known.

SHA-1 Depreciation Enforcement Microsoft Windows SHA-1 deprecation enforcement is done either through Microsoft Windows or its

browser technologies (i.e. Edge/IE). When an application calls WinVerifyTrust, which all Microsoft PKI

certificate-consuming applications do, the discovered certificates will be checked for “weak crypto”. The

weak crypto check (http://support.microsoft.com/en-us/kb/2862966) is not applied to certificates in

kernel mode, SYSTEM, and drivers with signatures verified by Code Integrity, and as covered before,

does not apply to certificates from private PKIs. Enforcement will be added by normally delivered

patches.

Note: Initially, SHA-1 enforcement involved Microsoft’s Smartscreen technologies. This is no longer the

case at this time. Microsoft’s SHA-1 enforcement only involves IE/Edge at this time.

In summary, as of now (February 2017), Microsoft's SHA-1 deprecation only impacts TLS certs signed by a SHA-1 hash 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 SHA-1 deprecation policies do not apply. CAs in the Windows Root Certification Program must have stopped issuing SHA-1 certificates as of Jan. 1, 2016.

Logging SHA-1 Certificates You can log the use of SHA-1 certificates by following the commands in this blog article:

https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation-roadmap/.

Disabling Microsoft Windows SHA-1 Deprecation Enforcement SHA-1 deprecation enforcement by Microsoft Windows can be disabled on supported Windows clients

by placing a REG_DWORD = 80000000 value in

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType

0\CertDllCreateCertificateChainEngine\Config:WeakSha1ThirdPartyFlags registry key.

The registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType

0\CertDllCreateCertificateChainEngine\Config\ exists today (and is used for controlling MD5

deprecation enforcement), but does not yet contain the WeakSha1ThirdPartyFlags registry key. Create

the WeakSha1ThirdPartyFlags registry key under

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType

0\CertDllCreateCertificateChainEngine\Config and enable the REG_DWORD value of 80000000 to

disable Windows SHA-1 deprecation enforcement.

The SHA-1 deprecation enforcement will be enabled by a future Windows Update which will update

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType

0\CertDllCreateCertificateChainEngine\Config\default:WeakSha1ThirdPartyFlags to REG_DWORD =

80800000. However, any settings under ..\Config take precedence over the settings under

..\Config\default when evaluated.

Be aware that disabling Microsoft Windows SHA-1 deprecation enforcement will only impact applications relying on Microsoft Windows cryptographic APIs and routines. Third party applications often do not use, or fully use, Microsoft Windows cryptographic handling, and will have their own enforcement handling.

Note1: Disabling SHA-1 deprecation enforcement is not recommended and if done will leave impacted clients in an elevated risk position.

Enabling Early Enforcement of SHA-1 Enforcement for Testing Purposes Many customers would like the ability to test Microsoft Windows’ SHA-1 enforcement ahead of the

2017 deadlines. This can be accomplished using the following commands from an elevated command

prompt:

set LogDir=C:\Log mkdir %LogDir% icacls %LogDir% /grant *S-1-15-2-1:(OI)(CI)(F) icacls %LogDir% /grant *S-1-1-0:(OI)(CI)(F) icacls %LogDir% /grant *S-1-5-12:(OI)(CI)(F) icacls %LogDir% /setintegritylevel L Certutil -setreg chain\WeakSha1ThirdPartyFlags 0x80900004 Use the following command at an elevated command prompt to remove the enabled settings after you have completed your testing: Certutil -delreg chain\WeakSha1ThirdPartyFlags Certutil -delreg chain\WeakSignatureLogDir

Note1: Prior to a planned November 2016 update, IE/Edge might not allow “click-through” when SHA-1

deprecation has been detected. This will be fixed with the November 2016 update.

Note2: Microsoft application SHA-1 behavior may change at anytime, so current testing may not equal a

future SHA-1 deprecation behavior if that behavior changes in the future.

Microsoft Legacy OS SHA-2 Support Here are the Microsoft Windows SHA-2 support statements:

• 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

• Windows 7 and Windows Server 2008 R2 needs a patch to support SHA-2 code signing and code signing verification (https://technet.microsoft.com/en-us/library/security/3033929.aspx). Windows 8 and Windows Server 2012 and later support SHA-2 code signing by default

• Windows versions earlier than Windows Server 2003 and Windows XP 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.

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 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 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 http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx 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, to the best of his ability. Statuses may change in future versions of this document based on

newly learned information.

• Web enrollment web site - supports SHA-2, but only using v2 templates

• Smartcards (PKINIT) - supported

• ADFS v.2.0 or later – does support SHA-2

Note (Jan. 6, 2016): Correction: Previous document versions incorrectly said ADFS did

not support SHA-2

• 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 – SHA-2 supported, https://technet.microsoft.com/en-

us/library/gg699362.aspx.

o Note: Feb. 25, 2016: Correction: Previous document versions incorrectly said

Configuration Manager did not support SHA-2.

• FIM-CM – Yes, SHA-2 supported.

o http://blogs.msdn.com/b/ms-identity-support/archive/2016/01/11/faq-for-fim-2010-to-

mim-2016-upgrade-and-sha2-support.aspx

o Note: Mar. 8, 2016: Correction: Previous document versions incorrectly said FIM-CM did

not support SHA-2.

• NDES/SCEP – Works with SHA-2 as long as you use a Microsoft CSP (Microsoft Enhanced RSA

and AES Cryptographic Provider) and enable a regedit. NDES signs responses by SHA-1 by

default, but can be changed to SHA-2 with the following command: certutil –setreg –f

mscep\HashAlgorithm\HashAlgorithm sha256 followed by an iisreset.

o Note (Jan. 22 2016): Previous versions of this document said incorrectly that NDES did

not support SHA-2.

• TLS 1.2 supports SHA-256 and SHA-384, but requires a patch

(https://support.microsoft.com/en-us/kb/2973337) to support 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

• TMG2010 does not support CNG, only CAPI

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

Manifest

SHA1, SHA256,

SHA384, SHA512

SHA1, SHA256 SHA1

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 (https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_3_1.pdf),

which states SHA-1 deprecation dates for Jan. 1, 2016 and Jan. 1, 2017. 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 - https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-

certificates/ • Google - https://googleonlinesecurity.blogspot.com/2015/12/an-update-on-sha-1-certificates-

in.html 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 Jan. 1, 2017.

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

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

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). 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 (https://cabforum.org/wp-

content/uploads/Baseline_Requirements_V1_3_1.pdf). 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 New 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 should be set to 0 for KSP. 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.

Configuring New 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. Note: If an ADCS CA was installed using a CSP, it must be migrated to a KSP to use SHA-1. Although once converted to a KSP, it can support either SHA-1 or SHA-2 hashes. If you need to convert an existing ADCS CA from a CSP to a KSP, follow the instructions in the next section.

Migrating Existing ADCS CA from SHA-1 CSP to SHA-2 KSP In order to migrate to SHA-2 in ADCS on an existing CA, most implementations will need to be running a

KSP. If the existing CA is running a CSP, the CA will need to be migrated to a KSP, and the involved CA

certificate converted from a CSP to a KSP (Note: The CA certificate itself, including all fields, including the

hash) will remain the same).

The detailed steps below discuss how to migrate a CA from being a SHA-1 signing CA using CSP to being

a SHA-256 KSP signing CA. These steps will keep/reinstall the same CA’s certificate(s), just update the

CA’s cryptographic service provider from legacy Cryptographic Service Provider (CSP) to current

standard, Cryptographic Next Generation (CNG) Key Storage Provider (KSP). After converting your CA

from CSP to KSP and setting the new hash signing algorithm, you will still need to renew the existing CA

certificates and get them signed by a SHA-2 signing parent CA (e.g. root CA) to get new SHA-2 signed CA

certificates.

Duration Planning Estimate: The steps below are quite involved. Plan on spending 1-2 hours per CA

conversion, on top of the time it takes to do the complete computer backup in step #1.

Backup and Document CA Before Modification

1. Do a complete backup of the CA computer.

Note: Do all commands below directly on targeted CA, unless otherwise instructed. All commands

should be done from the security context of a local Administrator. All command prompt commands

should be done from an elevated command prompt.

2. Backup CA database, from an elevated command prompt using: a. certutil.exe -backupdb [directory for backup] keeplog

3. Backup up Certificate Services registry keys separately, using regedt32.exe and file, export or reg export HKLM\SYSTEM\CurrentControlSet\services\CertSvc c:\[Your Backup Directory]\[filename].reg

4. Document all ADCS settings (which have to be re-created during the re-install), by using the Certification Authority console (certsrv.msc), right-click the CA name, choose Properties, then go on all tabs and document all settings (screenshots are a good way to document), especially the AIA and CDP locations, and Security tab. For the Security tab note all members and their permissions so you can recreate later. Also document revocation settings (by checking the settings by right-clicking the Revoked Certificates container and the Templates container, documenting which templates are published on the CA.

5. Apply any needed critical patches and/or hotfixes. Reboot as needed. a. Use https://pkisolutions.com/adcs-hotfixes/ to see a list of possible ADCS hotfixes

6. Stop Certificate Services a. At elevated command prompt, type: net stop certsvc and ENTER b. Or use ADCS GUI (certsrv.msc)

7. Display CA certificate information using: a. Certutil –store my [“Your CA common name”] b. You will see more than one CA certificate if older (renewed) CA certificates are present

8. Save a copy of CA certificate information to a file: a. Certutil –store my [“Your CA common name”] >c:\[backup directory]\[filename.txt] b. Note the Certificate Hash (SHA1) field for each CA certificate displayed, as you’ll be needing

it in a few commands or run certutil –getreg CA\CACertHash or certutil –getreg CA\CACertHash >CAhashes.txt to save CA hashes to separate file for future reference.

c. Note Key Container Name(s) for future use i. or run: certutil -store my CAName | findstr "/C:Key Container" just to get key

container name(s) ------------------------------------------------------------------------------------------------------------------------------------

Note: Commands for non-HSM: Run the commands, 9-14 in this section if you do not have an involved

HSM, otherwise if you have a Thales nCipher HSM run the commands in the next section instead

(starting at instruction #15):

9. Backup CA certificate and private key to a physical file (.P12) using the following command: a. Certutil -backupkey [filename] b. Put in password to protect the private key as prompted, and remember/write down

password c. This command copies CA certificate with private key to a subdirectory and filename.p12

Delete Current CA Certificate(s)

10. Delete current CSP-signed CA certificate(s) and private key(s) using the following command: a. For WS2012 or later:

i. Open elevated Powershell window and type: ii. Cd cert:\localmachine\my and hit ENTER

iii. Del –deletekey [Certificate Hash without spaces] and hit ENTER iv. Repeat for each involved CA certificate

b. For WS2008R2 or if you don’t want to use Powershell: i. Delete all CA certificate(s) in Local Machine store using:

1. mmc.exe, select Add/Remove Snap-in, choose the Certificates snap-in, Computer Accounts, Local Machine, open Personal Store\Certificates and delete all CA certificates

ii. Run Certutil –csp [“Your current CSP”] -delkey [Key Container Name] for each previously noted Key Container

Convert CA Certificate/Keys From CSP to KSP

11. Convert CSP-protected CA private key to new KSP using the following command: a. Import key to KSP by running:

i. Certutil –csp [”KSP name”] -importpfx [Your CA cert/key PFX file] 12. Export KSP-protected key to PFX so we can re-install it on CA by running:

i. Certutil –exportpfx my [“CA Common Name”] [PFX filename.pfx/path for export]

Note: If you have a pre-WS2012R2 CA, you must copy the CA’s private key (.p12) to and do the

importpfx and exportpfx process on a Windows 8.1/2012R2 (or later) computer and then export and

copy resulting pfx back to original CA server. Don’t forget to delete the keys temporarily copied, created,

and exported from the temporarily involved computer after you are finished.

13. On the original CA run: Certutil –restorekey [PFX filename/path] 14. Continue with command instruction #20 ----------------------------------------------------------------------------------------------------- Note: Thales nCipher HSM Commands: Run command instructions #15-19 if a Thales nCipher HSM is involved. Run the following commands from C:\Program Files (x86)\nCipher\nfast\bin> from an elevated command prompt: 15. Run csputils -m -d -n "[Key Container]"

Get and record the Key Hash from the correct key container

16. Run cngimport --import --machine-key --key=[Key Hash] –appname=mscapi [NewContainerName] 17. Run cnglist --list-keys

Return should list your [NewContainerName] 18. Run certutil -f -repairstore -csp "nCipher Security World Key Storage Provider" my "[CACertHash]"

If return message says, "CertUtil: -repairstore command completed successfully.", then the CSP to KSP conversion is completed. Otherwise troubleshoot.

19. Continue with instruction #20.

20. Uninstall/Remove ADCS Role. Reboot. 21. Make sure appropriate capolicy.inf file exists in c:\Windows or create one, if you don’t know what it

should have, use this one (modify as necessary): [Version]

Signature="$Windows NT$"

[Certsrv_Server]

RenewalKeyLength=2048

RenewalValidityPeriod=Years

RenewalValidityPeriodUnits=10

LoadDefaultTemplates=0

22. Reinstall ADCS using Server Manager a. Choose Use Existing Private Key option when displayed, then Select a certificate and use its

associated private key, and choose the newly imported CA certificate and key. b. Enable the Allow administrator interaction when the private key is accessed by the CA

option, if needed for HSM interaction.

c. Finish install accepting defaults or selecting appropriate options as needed. A reboot is not

usually needed.

After Success Certificate Services Re-Install 23. Using regedt32.exe confirm or change the following project-related registry values under

[HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\[CAName]\CSP\: a. Change ProviderType to 0, if not already 0. b. Change Provider to "[Your wanted KSP]", if not already correct value. c. Change CNGHashAlgorithm to SHA256, if desired

24. Using regedt32.exe confirm or change the following project-related registry values under HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\[CAName]\EncryptionCSP\

a. Change ProviderType to 0, if not already 0. b. Change Provider to "[Your wanted KSP]", if not already correct value.

25. Using regedit32.exe confirm or change all critical registry keys (you can review the registry backup performed near the beginning of this project). At a minimum, confirm the following additional registry keys and their values:

a. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\DBDirectory b. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\DBLogDirectory c. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\DBSystemDirectory d. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\DBTempDirectory e. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CACertPublicati

onURLs (Note: These values may be easier to set using Certification Authority console) f. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CAServerName g. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ClockSkewMinu

es h. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CommonName i. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLDeltaOverla

pPeriod j. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLDeltaOverla

pUnits k. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLDeltaPeriod l. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLDeltaPeriod

Units m. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLOverlapPe

riod

n. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLOverlapUnits

o. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLPeriod p. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLPeriodUnits q. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CRLPublication

URLs (Note: These values may be easier to set using Certification Authority console) r. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ValidityPeriod s. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ValidityPeriodU

nits t. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ExitModules u. HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\PolicyModules v. Exit the registry editor when finished

26. Make sure all former published templates are represented in the Certificate Templates container. 27. At an elevated command prompt, type in:

a. certutil -setreg CA\DSConfigDN CN=Configuration,DC=contoso,DC=ad ::Note: Field highlighted in yellow should equal forest root DN

28. Restore the original CA database (the re-install installed a blank CA database) by running: a. Stop Certificate Services, if not already stopped b. Certutil.exe -restoredb -f [backupdirectory]

29. Run the following command at an elevated prompt to ensure that certificate template changes are logged:

a. certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD 30. Run the following command at an elevated prompt if subject alternative names (SANS) support is

needed: a. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

31. Run the following command at an elevated prompt if OCSP response signing certificates are issued by this CA:

a. certutil –setreg CA\UseDefinedCACertInRequest 1 32. Restart Certificate Services 33. Start the Certification Authority console (certsrv.msc) and modify all existing CA server properties

and revocation values back to their originals. (Note: Make sure to re-add published certificate templates under the Certificate Templates folder).

34. Restart Certificate Services 35. Run certutil.exe -ping to test that CA is ready to receive requests. 36. Run pkiview.msc to make sure everything is working OK. 37. Test requesting and generating new certificates, to confirm they are issued as SHA-2. Note: Regular CA mitigation instructions can be found here: https://technet.microsoft.com/en-us/library/ee126140%28v=ws.10%29.aspx.

Converting Existing KSP SHA-1 CA to SHA-2 If you have a ADCS CA running a KSP, but it is still SHA-1 enabled, you can convert it from SHA-1 to SHA-2

with a simple regedit and restart Certificate Services. Using regedt32.exe confirm or change the

following project-related registry value under:

[HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\[CAName]\CSP\:

a. Change CNGHashAlgorithm to SHA256 (or other SHA-2 key size as desired)

b. Exit the registry editor c. Restart Certificate Services

This will result in the Hash algorithm value displayed under the Cryptographic Settings showing the new SHA-2 signing algorithm (as shown in the figure below).

This change will make all new issued certificates and CRLs be signed by the new signing algorithm as

displayed in the Hash algorithm field. However, it will not impact how the current CA certificate is

signed. You will need to get a new CA certificate, signed by a SHA-2 signing parent CA (e.g. root CA) to

also have the CA certificate signed by SHA-2.

Most SHA deprecation policies require both the endpoint digital certificate and all CA certificates in the

same PKI hierarchy be SHA-2 signed to meet the SHA-1 deprecation requirements.

Renewing a Child CA Certificate with an Offline Parent CA To get a new CA certificate signed by a SHA-2 parent CA, you will need to make sure the parent CA is or

has been converted to SHA-2, and renew the child CA’s existing CA certificate. The steps to do this are:

For each child CA needing certificate renewal:

Note: If HSM is involved, make sure HSM is active and contactable with necessary HSM procedures

either done ahead of time or prepared for.

1. Log on to the child CA computer as member of the Enterprise Admins group.

2. Open Certification Authority console.

3. In the console tree, right-click the name of the certification authority (CA).

4. On the Action menu, point to All Tasks, and click Renew CA Certificate.

5. Click Yes, to generate a new public and private key pair for the certification authority's

certificate.

6. Click Save to create the request to a file (note name), which will be saved to C:\.

o Copy request file to removable media/USB key, to take to the offline root CA.

Get the root CA and booted up and logged in

1. Locate offline root CA (stored in safe, secure location). Collect together necessary personnel to

successfully access and logon to root CA.

2. Power on offline root CA. Supply boot up password if required.

3. Logon to Windows as member of the local Administrators group.

4. Ensure that the removable media device can be accessed by the root CA.

On the root CA, perform the following for each needed issuing CA renewal:

1. After a successful logon, open Certification Authority MMC console.

2. Right-click the name of the root CA, click All tasks, click Submit new request…

3. Browse to the request file from the child CA on the removable media.

4. Once the request is processed, click the Pending requests node, select the request, right-click

and choose Issue.

5. Click the Issued certificates node and double-click the related issued CA certificate.

6. Click the Details tab and review, especially the useful life of the certificate and AIA and CDP path

locations. If there are errors, errors will need to be corrected and another CA certificate

generated, before continuing.

7. If the certificate is correct, continue. Click Copy to file box to copy the new CA certificate to

removable media. Choose the P7B certificate format option.

8. Follow the prompts and copy the issued certificate file to removable media and back to the

related child CA.

9. If you have additional child CA certificates to renew, repeat the steps above for each involved

issuing CA. When all needed issuing CAs have had their certificates renewed, continue with the

next steps.

For each child CA with a renewed certificate:

10. On the child CA, open the Certification Authority MMC and right click the CA name.

11. Choose Install CA Certificate option and browser to the newly issued certificate on the

removable media.

12. After the new subCA certificate is installed, if the CA didn’t automatically re-start, start the CA

service (using the Certification Authority console).

13. Renewed CA certificate should now be installed on issuing CA and the issuing CA up and running.

Copy new CA certificate if needed to any external AIA sites not automatically handled by

automation. Otherwise troubleshoot any errors.

When finished renewing all needed child CA certificates:

14. If you are finished with the root CA, you can shut it down and store back in its safe, secure

location.

Don’t Forget To Update OCSP After Updating the CA Certificate Note: If your CA’s revocation information is supported by Online Certificate Status Protocol (OCSP)

Responders, you’ll need to make sure the OCSP Responder has an additional revocation configuration

created for each newly issued CA certificate (that is represented by the OCSP Responder service).

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

Certificate Request Information This section covers certificate requests and certificate request signing.

In general, regardless of the certificate request, the resulting ADCS-issued certificate's hash is dictated

by the hash designated in the CA’s server’s Cryptographic Settings

Creating SHA-2 Certificate Requests Some CAs (not ADCS, as of 3-21-17) require that submitted certificate requests be signed by SHA-2. This

is not a Microsoft, CABForum, and general industry requirement. Microsoft currently (as of 3-21-17)

does not have any tools which make SHA-2 certificate requests signed by SHA-2 by default. However,

there are many ways to create a SHA-2 signed certificate request, including using mmc.exe and

certreq.exe.

Request Signing Confusion and Certificate Templates 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 designated in the CA’s Cryptographic Settings, which is applicable to all issued certificates and CRLs (and is not directed by any setting in the template).

Miscellaneous ADCS SHA-2 Facts • 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.

Other Related Reading • NIST SHA-3 Standard: http://www.nist.gov/itl/csd/201508_sha3.cfm

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

Conclusion Because of further cryptographic weaknesses in the SHA-1 hash, it is likely that SHA-2 signed certificates, particularly for TLS connections, 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 Certificate Services.