I was recently helping a customer deploy a SHA-256 based PKI.  As part of the retirement of their old PKI, we reissued the code signing certificates used by their developers.  We found that the Visual Studio 2010 developers had no issue with the new code signing certs, but the Visual Basic of Application developers could not select the new SHA-256 certificate.  Working with the good folks in Premier Support, we discovered there was a bug in VBA.

Last week we released a hotfix for Office 2010, KB 2598139, that addressed this bug in Office 2010.  This hotfix corrected the issue with the certificate selection box (Tools | Digital Signature) and the handling of VBA macros signed with SHA2 certificates.

In order to properly use SHA2 code signing certificates, this hotfix would need to be installed on both the developer computers and the end-users computers.  As this is a QFE, the standard warning applies: …this hotfix is intended to correct only the problems that are described in this article. Apply this hotfix only to systems that are experiencing the problems described…  In order to download this hotfix, click the “View and request hotfix downloads” button on the top of the KB article.

-Adam Stasiniewicz

I was recently helping a customer deploy a SHA-256 based PKI.  As part of the retirement of their old PKI, we reissued the code signing certificates used by their developers.  We found that the Visual Studio 2010 developers had no issue with the new code signing certs, but the Visual Basic of Application developers could not select the new SHA-256 certificate.  Working with the good folks in Premier Support, we discovered there was a bug in VBA.

Last week we released a hotfix for Office 2010, KB 2598139, that addressed this bug in Office 2010.  This hotfix corrected the issue with the certificate selection box (Tools | Digital Signature) and the handling of VBA macros signed with SHA2 certificates.

In order to properly use SHA2 code signing certificates, this hotfix would need to be installed on both the developer computers and the end-users computers.  As this is a QFE, the standard warning applies: …this hotfix is intended to correct only the problems that are described in this article. Apply this hotfix only to systems that are experiencing the problems described…  In order to download this hotfix, click the “View and request hotfix downloads” button on the top of the KB article.

-Adam Stasiniewicz

I was recently helping a customer deploy a SHA-256 based PKI.  As part of the retirement of their old PKI, we reissued the code signing certificates used by their developers.  We found that the Visual Studio 2010 developers had no issue with the new code signing certs, but the Visual Basic of Application developers could not select the new SHA-256 certificate.  Working with the good folks in Premier Support, we discovered there was a bug in VBA.

Last week we released a hotfix for Office 2010, KB 2598139, that addressed this bug in Office 2010.  This hotfix corrected the issue with the certificate selection box (Tools | Digital Signature) and the handling of VBA macros signed with SHA2 certificates.

In order to properly use SHA2 code signing certificates, this hotfix would need to be installed on both the developer computers and the end-users computers.  As this is a QFE, the standard warning applies: …this hotfix is intended to correct only the problems that are described in this article. Apply this hotfix only to systems that are experiencing the problems described…  In order to download this hotfix, click the “View and request hotfix downloads” button on the top of the KB article.

-Adam Stasiniewicz

Since my last post about SHA2 and Windows I’ve received numerous questions from customers and partners around three particular scenarios.  This post will try to address those questions.

Windows XP/2003 Enrollment in SHA2 Signed Certificates

As covered in the previous post, Windows XP Service Pack 3 clients with KB 968730 can enroll SHA2 signed certificates.  But looking at the Certificate Templates MMC for a version 2 template, it is not very clear how to configure SHA2.  Version 3 templates include an option about hashing algorithms, but Windows XP can’t enroll in version 3 templates (Vista or newer is needed for that).  So several customers have asked how to configure XP and 2003 clients to enroll in SHA2 certificates. 

The answer is actually very simple.  Once a CA is configured with a SHA2 at install, all certificates it issues will use the same hash.  The “request hash” setting on Version 3 templates refers to the hash used only in the generation of Certificate Signing Requests (CSR).  The CSR is only used during the certificate enrollment process, and a new hash is generated and attached to the final certificate by the CA.

Migrating to new PKI Hierarchy

Several customers have expressed a desire to migrate from their old SHA1 PKI hierarchy to a new hierarchy based completely on SHA2.  While a full write-up of what is required would take several blog posts, I just wanted to cover a few points that are sometimes overlooked.

1. Keep in mind the process which Windows uses to build certificate chains.  A very nice write-up of the process was posted previously to this blog.  That being said, it is strongly recommended that clients not have to rely on AIA paths to build certificate chains.  Rather, the new PKI’s hierarchy should be deployed in advance using Group Policy or “certutil -dspublish”. By placing the CA certificates locally on the clients, the administrator can both influence the path clients choose when they encounter cross certification and will ensure that outages of AIA path servers don’t affect a client’s ability to build a chain.
2. On a similar note, ensure that any new CAs that are issuing end entity certificates are listed in the NTAuthCertificates object.  The process to add them is detailed here and here.
3. Some applications do not support SHA2.  Before using SHA2 signed certificates with a specific application, it is recommended that all PKI dependent components of that application be tested.  For example, if SHA2 will be used for S/MIME; then every email client, email server, relay, spam filter, security device, etc belonging to both one’s own organization and those of external organizations (which exchange S/MIME messages with one’s organization) would need to be validated that they can process S/MIME with SHA2. For this reason, both old and new PKI hierarchy may need to operate while applications are upgraded/migrated.

Clarification on Support for SHA2 and Windows XP/2003

There was some concern with the pervious blog post about exactly what scenarios Microsoft officially supports and does not.  To be clear, the table at the bottom of the post was intended to share test results, rather than an official support statement (this is why the word “works” not “supported” was used in the table).  Our official support statement is contained within KB 968730:

Windows XP SP3 implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in the X.509 certificate validation. The changes in the certificate validation are meant to enable the scenario of the SSL/TLS authentication. Other scenarios that involve certificate validation may not work if you use certificates that are secured by using the SHA2 algorithms if the protocols and the applications do not support the SHA2 hashing algorithms. For example, the S/MIME signed e-mail verification and the Authenticode signature verification do not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3.

That being said, Windows XP and Server 2003 are getting very close to the end of their support lifecycle.  At the time of writing, only XP SP3 and 2003 SP2 are supported and only under the terms of Extended Support.  Windows XP extended support will end on 4/8/2014.  After 4/8/2014 customers will no longer be able to receive support from Microsoft and no new security hotfixes (including those for critical vulnerabilities) will be released for XP/2003.  Customers are strongly encouraged to migrate systems to Windows Vista/2008 and newer. 

I hope that clears up any questions.

-Adam Stasiniewicz

UPDATE (2/8):  Based on some recent questions, additional information has been posted about SHA2 and Windows.

Introduction

We’ve recently received a couple of requests from customers around the functionality of SHA-256 when running on Windows XP and 2003. This has been more important recently, as NIST has recommended the migration off of SHA-1 by end of the year. More details about the NIST recommendation can be found in SP 800-78-2 and SP 800-57. Hopefully this blog post can help clear up the confusion surrounding scenarios that work and the ones that don’t.

Windows XP Support

Prior to Windows XP Service Pack 3, there was no SHA2 functionality within Windows XP. With the release of Service Pack 3 some limited functionality was added to the crypto module rsaenh.dll. This includes the following SHA2 hashes: SHA-256, SHA-384, SHA-512. SHA-224 was not included.

Windows Server 2003 Support

Windows Server 2003 Service Pack 2 does not ship with support for SHA2. This limitation can become an important concern when processing smart card logons and for mutual TLS authentications to web servers. As unlike other technologies, smart card logon and mutual TLS both use strict revocation checking; so should either the certificate itself or the revocation information (CRL/OCSP) use SHA2, the logon would fail.

KB 938397

Though support SHA2 is not included in Windows Server 2003 Service Pack 2, it is available for download. KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3. KB 938397 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 938397 is also offered for Windows Server 2003 Service Pack 1.

KB 968730

With the release of Windows Server 2008 it was found that Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2 with KB 938397 were unable to request certificates from a Windows Server 2008 (and 2008 R2) certificate authority (CA) who’s certificate was signed with a SHA2 hash. KB 968730 was release to address this issue. Incidentally, KB 968730 completely supersedes KB 938397; so if a Windows Server 2003 Service Pack 2 system would need to both enroll from a SHA2 certificate authority and process SHA2 certificates, only KB 968730 would need to be installed. As before, KB 968730 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 968730 is not offered for Windows Server 2003 Service Pack 1.

Windows Vista, 7, Server 2008, and Server 2008 R2

Starting with Windows Vista and Server 2008, the Cryptography Next Generation (CNG) Suite B algorithms (including SHA2) are included in the operating system. It is worth noting that even though the algorithms are available, it is up to the individual applications to implement support.

Outlook and S/MIME

Besides logon, another very popular use for smart cards is S/MIME. But before diving into Outlook and S/MIME, the following warning should be given: Regardless of the functionality Windows and Outlook provide; in order for mail to be delivered between two users, there are any number of spam filters, relays, mailboxes, etc between sender and recipient. Each of these can be made by a wide range of vendors; running on a wide range of platforms. So before deploying SHA2, testing should be done against one’s own email infrastructure, in addition to the email infrastructure of external organizations from whom S/MIME signed mail needs to be exchanged with.

All those warnings aside, the basic functionality for Outlook is a follows. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when that certificate itself is SHA2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message itself is SHA2 signed (regardless of the certificate used). Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot sign a message with SHA2; only SHA-1 and MD5 are available.

In order to validate SHA2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.

Recommendations

For organizations looking to deploy SHA2 or organizations that interact with 3^rd parties that will soon begin using SHA2, the following is recommended.

• If Windows XP is used in the environment, Service Pack 3 should be deployed. In addition to SHA2 functionality, Service Pack 3 is currently the only Windows XP service pack that is supported.
• If Windows XP systems would need to enroll in certificates from a SHA2 certificate authority, KB 968730 should be deployed.
• If Windows Server 2003 is used in the environment, Service Pack (1 or 2) and KB 938397 should be deployed.
• If Windows Server 2003 would need to enroll in certificates from a SHA2 certificate authority, Service Pack 2 and KB 968730 should be deployed. If planning on deploying KB 968730, installing KB 938397 is not necessary.
• If S/MIME using SHA2 signing for the message body is needed, workstations should be upgraded to at least Windows Vista running Office 2003.

Summary Chart

-Adam Stasiniewicz

UPDATE (2/8):  Based on some recent questions, additional information has been posted about SHA2 and Windows.

UPDATE (2/8):  Based on some recent questions, additional information has been posted about SHA2 and Windows.

Introduction

We’ve recently received a couple of requests from customers around the functionality of SHA-256 when running on Windows XP and 2003. This has been more important recently, as NIST has recommended the migration off of SHA-1 by end of the year. More details about the NIST recommendation can be found in SP 800-78-2 and SP 800-57. Hopefully this blog post can help clear up the confusion surrounding scenarios that work and the ones that don’t.

Windows XP Support

Prior to Windows XP Service Pack 3, there was no SHA2 functionality within Windows XP. With the release of Service Pack 3 some limited functionality was added to the crypto module rsaenh.dll. This includes the following SHA2 hashes: SHA-256, SHA-384, SHA-512. SHA-224 was not included.

Windows Server 2003 Support

Windows Server 2003 Service Pack 2 does not ship with support for SHA2. This limitation can become an important concern when processing smart card logons and for mutual TLS authentications to web servers. As unlike other technologies, smart card logon and mutual TLS both use strict revocation checking; so should either the certificate itself or the revocation information (CRL/OCSP) use SHA2, the logon would fail.

KB 938397

Though support SHA2 is not included in Windows Server 2003 Service Pack 2, it is available for download. KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3. KB 938397 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 938397 is also offered for Windows Server 2003 Service Pack 1.

KB 968730

With the release of Windows Server 2008 it was found that Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2 with KB 938397 were unable to request certificates from a Windows Server 2008 (and 2008 R2) certificate authority (CA) who’s certificate was signed with a SHA2 hash. KB 968730 was release to address this issue. Incidentally, KB 968730 completely supersedes KB 938397; so if a Windows Server 2003 Service Pack 2 system would need to both enroll from a SHA2 certificate authority and process SHA2 certificates, only KB 968730 would need to be installed. As before, KB 968730 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 968730 is not offered for Windows Server 2003 Service Pack 1.

Windows Vista, 7, Server 2008, and Server 2008 R2

Starting with Windows Vista and Server 2008, the Cryptography Next Generation (CNG) Suite B algorithms (including SHA2) are included in the operating system. It is worth noting that even though the algorithms are available, it is up to the individual applications to implement support.

Outlook and S/MIME

Besides logon, another very popular use for smart cards is S/MIME. But before diving into Outlook and S/MIME, the following warning should be given: Regardless of the functionality Windows and Outlook provide; in order for mail to be delivered between two users, there are any number of spam filters, relays, mailboxes, etc between sender and recipient. Each of these can be made by a wide range of vendors; running on a wide range of platforms. So before deploying SHA2, testing should be done against one’s own email infrastructure, in addition to the email infrastructure of external organizations from whom S/MIME signed mail needs to be exchanged with.

All those warnings aside, the basic functionality for Outlook is a follows. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when that certificate itself is SHA2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message itself is SHA2 signed (regardless of the certificate used). Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot sign a message with SHA2; only SHA-1 and MD5 are available.

In order to validate SHA2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.

Recommendations

For organizations looking to deploy SHA2 or organizations that interact with 3^rd parties that will soon begin using SHA2, the following is recommended.

• If Windows XP is used in the environment, Service Pack 3 should be deployed. In addition to SHA2 functionality, Service Pack 3 is currently the only Windows XP service pack that is supported.
• If Windows XP systems would need to enroll in certificates from a SHA2 certificate authority, KB 968730 should be deployed.
• If Windows Server 2003 is used in the environment, Service Pack (1 or 2) and KB 938397 should be deployed.
• If Windows Server 2003 would need to enroll in certificates from a SHA2 certificate authority, Service Pack 2 and KB 968730 should be deployed. If planning on deploying KB 968730, installing KB 938397 is not necessary.
• If S/MIME using SHA2 signing for the message body is needed, workstations should be upgraded to at least Windows Vista running Office 2003.

Summary Chart

-Adam Stasiniewicz

UPDATE (2/8):  Based on some recent questions, additional information has been posted about SHA2 and Windows.