Freigeben über

Common Questions about SHA2 and Windows

  • Artikel

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

Comments

  • Anonymous
    January 01, 2003
    CRLs are signed with the same algorithm that was selected at CA install.

  • Anonymous
    February 09, 2011
    Very useful Adam, thank you!

  • Anonymous
    June 11, 2012
    The comment has been removed

  • Anonymous
    June 21, 2012
    The comment has been removed

  • Anonymous
    July 16, 2015
    Die

  • Anonymous
    August 19, 2016
    The comment has been removed