Table of Contents

 


Overview

Effective February 14, 2017, Windows (version 7 and higher) and Windows Server will no longer trust new code that is signed with a SHA-1 code signing certificate for Mark-of-the-Web related scenarios (e.g. files containing a digital signature) and that has been time-stamped with a value greater than February 14, 2017. This cut-off date applies to the code-signing certificate itself.

This restriction will not apply to the time-stamp certificate used to time-stamp the code-signing certificate or the certificate’s signature hash (thumbprint) until February 14, 2017. After this time, Windows will treat any code with a SHA-1 time-stamp or SHA-1 signature hash (thumbprint) as if the code did not have a time-stamp signature.

Drivers with signatures verified by Code Integrity are not affected by this change. For more information about how to conform to the latest requirements for driver signing, see the Windows Hardware Certification Blog.

 

 Note
As of October, 2015 Microsoft has replaced all references to "SSL" with " TLS"

 

 Note
This policy only applies to roots that are part of the Microsoft Trusted Root Certificate Program.

 

 Note
The dates specified in this policy go into effect at 00:00 UTC on the date specified.

 

Back to top


Enforcement in General

  1. Server-Authentication Certificates: In summer 2016, Internet Explorer and Edge will stop showing the lock icon on web pages secured with SHA-1 certificates. More details are located here. Effective February 14, 2017, Windows will no longer trust certificates signed with SHA-1 after 2/14/2017.
  2. Code Signing Certificates: Windows will no longer trust files with the Mark of the Web attribute that are signed with a SHA-1 code signing certificate and are timestamped after 1/1/2016. With the exception of issuing certificates to developers who intend to develop only applications for Windows Vista, Windows Server 2008, CAs may not issue new SHA-1 code signing certificates after January 1, 2016.
  3. Timestamping Certificates: Windows will treat any certificate with a timestamp date after February 14, 2017, as if the file was not timestamped. However, if pre-image attacks on SHA-1 become feasible we will reevaluate how the system trusts these certificates. With the exception of issuing certificates to developers who intend to develop only applications for Windows Vista, Windows Server 2008, CAs may not issue new SHA-1 code signing certificates after January 1, 2016.
  4. S/MIME Certificates: Windows will not enforce specific policies on S/MIME certificates. However, if pre-image attacks on SHA-1 become feasible we will reevaluate how the system trusts these certificates. Microsoft recommends that CAs start issuing new certificates using the SHA-2 algorithm.
  5. OCSP and CRL Signing Certificates: Windows will also not enforce policies on these certificates. Microsoft recommends that CAs move to using SHA-2 wherever practicable.
  6. OCSP Signatures: Windows will no longer trust OCSP responses that use SHA-1 for their signature after January 1, 2016, if the corresponding certificate has the Must Staple extension January 1, 2016.
  7. OCSP Responses. Windows will no longer trust OCSP responses that use SHA-1 for any TLS certificates after February 14, 2017. SHA-1 TLS certs without the must staple extension can continue to be served with SHA-1 OCSP signatures. Microsoft requires CAs to start issuing new OCSP signatures using only the SHA-2 algorithm after January 1, 2016 for SHA-2 TLS certificates
  8. CRL Signatures: Microsoft does not require that CAs move to using SHA-2 for CRL signatures, and Windows will not enforce policies on these certificates. However, if pre-image attacks on SHA-1 become feasible we will re-evaluate how the system trusts these certificates.
  9. Code signature File Hashes: Microsoft does not require these file hashes to be done using SHA-2. Windows will also not enforce policies on these hashes. If pre-image attacks on SHA-1 become feasible we will reevaluate how the system trusts signatures made with such file hashes.
  10. Timestamp Signature Hashes: Windows will no longer trust files with the Mark of the Web attribute that are timestamped with a SHA-1 signature hash after February 14, 2017, on Windows 10 systems. Microsoft requires CAs to start issuing new timestamp signature hashes using only the SHA-2 algorithm after 1/1/2016. For developers targeting Windows Vista and Server 2008, CAs will be allowed to continue issuing SHA-1 timestamps.

 

Back to top


Concerns with MSIs

Code Signing Guidance

Signature Verification Failure Experience

IE

Edge

Files downloaded through browsers that set the Mark-of-the-Web will go through SmartScreen on Windows 8 and higher systems and files not compliant with policy will run into the following experience:

 

Back to top


Verifying Code Signatures

There are a couple ways to figure out how a particular file is signed. Signatures embedded on a file can be viewed using the Digital Signature tab in file properties or the SDK command-line utility signtool can be used to enumerate the signatures on a file.

Signtool approach

Use the following steps to view the signature on a file:

  •  Install the Windows SDK
  • Open a command prompt window to invoke signtool
  • The following cmdline invocation will list the signature information for the file including the hash of the file and the algorithm used to compute it and the timestamp time.

    signtool.exe verify /pa /v <foo.exe>>

The signtool invocation will also display the thumbprint of the certificate as the SHA1 hash field. This information can be used in conjunction with certutil to determine the hash algorithm of the code signing certificate. The following command line will dump information about all the certificates used to sign and timestamp the specified file

certutil.exe –dump <foo.exe>

The signature algorithm field will mention the hash algorithm and the public key algorithm used for the certificate.

Digital signature tab approach

Use the following steps to view the signature on a file:

  •  Right click the file you want to inspect and select the ‘Properties’ option
  •  Select the ‘Digital Signatures’ tab
  • The Signature list will tabulate all the signatures that are present on the file. The algorithm used to hash the file is listed in the ‘Digest Algorithm’ field. To determine additional details on the file select a signature on the list and click the ‘Details’ button
  • The Digital Signature Details provides a lot more information. The timestamp of the signature is listed in the ‘Signing time’ field. Select the ‘View Certificate’ button to view more information on the certificate and select the ‘Details’ tab to find the hash algorithm of the certificate which will be specified in the ‘Signature hash algorithm’ field.

The items in red are highlighted are marked on the following screenshots. The items of interest for the policy enforced by KB 3123479 are the Signature hash algorithm and Signing time. KB 3123479 requires that any files signed after 1/1/2016 that are being distributed over the internet and maybe downloaded through a browser are signed with a SHA-2 certificate. Here is a simple cheat sheet:

Signature hash algorithm value

Signing time value

Behavior

SHA1

Earlier than 1/1/2016

No signature verification failures due to policy

SHA1

After 1/1/2016

Signature verification will fail in IE and Edge download checks and SmartScreen’s prompt

SHA2

Any value

No signature verification failures due to policy

 

 

 

Back to top


Signing Guidance

Lots of software is distributed through MSIs and we recognize that developers will want to try and maintain as simple a distribution as possible. Given the enforcement matrix in Appendix A, it is possible to ship a single MSI that is appropriately trusted on all down-level editions of Windows by signing the MSI with a SHA-2 code signing certificate while maintaining a SHA-1 file hash.

EXE files can be multiple signed and the modern AppX platform supports SHA-2 signatures. These solutions can provide alternatives for developers looking for cryptographically agile deployment mechanisms.

 

Back to top

How to dual sign files

PE files like EXEs and DLLs can be dual signed. If a single executable needs to work on all Windows systems down to Windows Vista dual signing the file is the best option.

Signtool, a Windows SDK utility, allows developers to perform dual signatures with the aid of the /as option for the sign command. The series of signtool invocations below offer an example of how to perform dual signing for a file:

signtool.exe sign /n <Subject name of SHA-1 certificate> /t <URL to SHA-1 Authenticode timestamp server> /v foo.exe

signtool.exe sign /n <Subject name of SHA-2 certificate> /fd sha256 /tr <URL to SHA-2 RFC-3161 timestamp server> /td sha256 /as /v foo.exe

 

Back to top

How to handle MSI files

Since the MSI file format does not support dual signing a different approach needs to be used for signing a single MSI to be conformant with the policy down to Windows Vista. The signtool invocation below offers an example of how to handle the SHA-1 code signing certificate requirement. Note that this approach will meet policy only for the code signing certificate requirement being enforced for SHA-1 code signing certificates starting on 1/1/2016.

signtool.exe sign /n <Subject name of SHA-2 certificate> /t <URL to SHA-1 Authenticode timestamp server> /v foo.exe

 

Back to top


Enforcement details

Certificate Type Windows Behavior Microsoft Policy
TLS certificates Certificates signed with SHA-1 will be untrusted after 2/14/2017 CAs must move all new certs to SHA-2 after 1/1/2016
Code signing certificates On Win 7 and above, untrusted on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files. CAs should issue new code signing certs with SHA-1 after 1/1/2016 only for developers targeting Vista/2008, otherwise, move all new certs to SHA2
S/MIME certificates No OS specific policies. Application policies. CAs are recommended to move to SHA-2
Time-stamping certificates No changes until SHA-1 preimage is possible CAs must issue new TS certs with SHA-1 after 1/1/2016 only for developers targeting Vista/2008, otherwise, move all new certs to SHA2
OCSP signing and CRL signing certificates No changes until SHA-1 preimage is possible No changes until SHA-1 preimage is possible
OCSP signatures

On Windows 10 and above for certificates with the Must Staple extension, SHA-1 signatures will not be accepted after 1/1/2016

On Windows 10 and above, SHA-1 signatures will not be accepted for any TLS certificate after 2/14/2017

CAs should move to using SHA-2 starting 1/1/2016 for SHA-2 TLS certificates.

CAs should prepare to move to SHA-2 for all TLS certificates by 2/14/2017

CRL signatures No changes until SHA-1 preimage is possible No changes until SHA-1 preimage is possible
Code signing signatures No changes until SHA-1 preimage is possible No changes until SHA-1 preimage is possible
Time-stamp signatures On Win 10 and above, blocked on 2/14/2017 for Mark of the Web files. CAs should move to using SHA-2 starting 1/1/2016

 

Back to top


Schedule

Now -> 12/31/2015 1/1/2016 -> 2/14/2017 ->
CAs Windows CAs Windows CAs Windows
TLS Certificates CAs can issue SHA-1 and SHA-2 SHA-1 and SHA-2 are supported CAs must issue SHA-2 only No change No change Windows trusts SHA- 2 only
Code Signing Certificates CAs can issue SHA-1 and SHA-2 SHA-1 and SHA-2 are supported CAs SHOULD issue SHA-2 only, unless developer is targeting Vista and Server 2008 (for them, CAs MAY issue SHA-1) Windows trusts SHA1 (if timestamped prior to 1/1/2016) and SHA-2 (any timestamp) for Mark of the Web files. (Note: no kernel mode enforcement) No change No change
Timestamp Certificates CAs can issue SHA-1 and SHA-2 SHA-1 and SHA-2 are supported CAs SHOULD issue SHA-2 only, unless developer is targeting Vista and Server 2008 (for them, CAs MAY issue SHA-1) No change No change No change
S/MIME Certificates CAs can issue SHA-1 and SHA-2, although Microsoft recommends SHA-2 SHA-1 and SHA-2 are supported No change No change No change No change
OCSP and CRL Signing Certificates CAs can issue SHA-1 and SHA-2 SHA-1 and SHA-2 are supported No change No change No change No change
OCSP Signatures CAs can sign OCSP responses with SHA-1 and SHA-2 SHA-1 and SHA-2 are supported CAs SHOULD sign OCSP responses with SHA-2 only Windows no longer trusts OCSP signatures made with SHA-1 for certificates with the Must Staple extension No change Windows no longer trusts OCSP signatures made with SHA-1 for any TLS certificate
CRL Signatures CAs can sign CRLs with SHA-1 and SHA-2 SHA-1 and SHA-2 are supported No change No change No change No change

 

Code Sign file hashes CAs can create file hashes using SHA-1 and SHA-2 SHA-1 and SHA-2 are supported No change No change No change No change
Timestamp signature hashes CAs can create timestamp signature hashes using SHA-1 and SHA-2 SHA-1 and SHA-2 are supported CAs SHOULD create timestamp signature hashes using SHA-2 only, unless developer is targeting Vista and Server 2008 (for them, CAs MAY use SHA-1) No change No change Windows no longer trusts files with th Mark of the Web attribute that are timestamped with SHA-1 signature ha on Windows 10 systems.

(Note: no kernel mode enforcement)

 

Back to top


Testing

The restriction will use the framework Microsoft published earlier to enforce this restriction. The policy will be applied to Windows 7 and higher systems (and the corresponding Server releases) through a Windows Update.

 

Back to top

Setting the policy manually

The following registry settings need to be set to enable the policy. The easiest means of doing so would be to use the inbox certutil tool but it is possible to directly manipulate the registry as well.

  • Description of change
    • Signed files that are time stamped after 1/1/2016 would be blocked.
  • WCF settings
    • WeakSha1ThirdPartyFlags = 80800000 (CERT_CHAIN_ENABLE_WEAK_SETTINGS_FLAG | CERT_CHAIN_DISABLE_MOTW_CODE_SIGNING_WEAK_FLAG)
    • WeakSha1ThirdPartyAfterTime = 0018DF076244D101 1/1/2016 (FILETIME)
  • Certutil invocations
    • certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x80800000
    • certutil -setreg chain\Default\ WeakSha1ThirdPartyAfterTime @1/1/2016

Note: For testing performed prior to 1/1/2016 it may be convenient to assign the time to a different earlier value

 

Back to top


Frequently Asked Questions

Can I test the OCSP signature enforcement on a current Windows system?

No – the functionality to enforce this requirement will be added to a future build of Windows 10.

 

Back to top

Can I issue SHA-1 OCSP responses for SHA-1 certificates and SHA-2 OCSP responses for SHA-2 certs?

Yes - within the constraints of the enforcement being performed for SHA-1 OCSP signatures. SHA-1 OCSP responses will not be trusted by Windows 10 and higher systems for certificates using the Must Staple extension after January 1, 2016. SHA-1 OCSP responses will not be trusted by Windows 10 and higher systems for all certificates (i.e. certificates without the Must Staple extension) after February 14, 2017.

 

Back to top

Does Microsoft have partners that provide SHA-256 time-stamping services?

Yes. The following Microsoft partners can provide SHA-256 time-stamping services:

 

Back to top

Does the OCSP signature enforcement apply to code signing certificates?

No, the OCSP signature enforcement requirements only apply to TLS certificates.

 

Back to top

For the policies being enforced for coed signing and timestamping certificates at what level of the PKI hierarchy is the policy being enforced at?

The policies will be enforced for all the certificates under the root certificate (i.e. the leaf and intermediate certificates)

 

Back to top

I am still targeting software for distribution to Windows XP SP1, SP2 and Windows Server 2003. How might I be affected by these requirements?

The deprecation policies will not be targeted at those systems. Those systems however do not have SHA-2 support and no patch is available to add that support either. Developers can use SHA-1 code signing certificates and SHA-1 file hashes to sign their code. SHA-1 timestamps should be used as well.

 

Back to top

There are many hashes in an OCSP response. Which hash is the enforcement going to be performed on?

The policy is aimed at the signature in the response i.e. the Signature member of the OCSP_SIGNATURE_INFO struct in an OCSP_BASIC_SIGNED_RESPONSE_INFO struct. There is no enforcement on content in the OCSP_SIGNED_REQUEST_INFO.

 

Back to top

Will ClickOnce manifest signature checks be affected by this policy?

No.

 

Back to top

Will downlevel clients be adversely affected from an application compatibility perspective by the OCSP signature enforcement?

No – the OCSP signature requirements will only be enforced on Windows 10 and higher systems which have full support for handling SHA-2 OCSP responses. TLS servers can get a certificate with the Must Staple extension and will not have any problems with downlevel clients that do not enforce the requirement.

 

Back to top

Will the policies apply to certificates that do not chain to a certificate issued by a CA in the Microsoft Root Certificate Program?

No, the policies will only apply to certificates issued by CAs in the Program.

 

Back to top

Will the policy impact certificates that chain up to an internal root that is not part of the Microsoft Trusted Root Program?

No. Only certificates that are in the Microsoft Trusted Root Program will be affected by the policies described here.

 

Back to top

Will there be any policy active on a client Windows machine for TLS certificates in January, 2016?

No – policy on a client Windows machine targeting TLS certificates will not be applied until January 2017

 

Is dual signing supported for catalog (.cat) files?

Dual signing a single catalog file is not supported. It is possible to sign the same content with multiple catalogs. Developers with compatibility concerns can catalog sign their content with two catalog files – one with SHA-1 and the other with SHA-2 and ship both catalogs as part of their software package.

Back to top