Sha256 windows xp sp3

Feb 12, 2025

Introduction

Index:

1. OS,   Browser, and Server Support
2. Firewall Support
3. Toolkits, Libraries, Frameworks, etc.
4. Database Support
5. Detailed Operating System Support
6. E-Mail Clients
7. Document Signing
8. Windows Code Signing
9. SafeNet iKey / eToken Compatibility
10. Mainframe
11. Citrix Support
12. Services

OS, Browser, and Server Support  

Firewall Support

Toolkits, Libraries, Frameworks, etc.  

Support for SHA-2 was introduced in OpenSSL 0.9.8, but is not enabled by default with SSL_library_init(). In 0.9.8, SHA-2 hash functions must be called specifically or by using OpenSSL_add_all_algorithms() which may not be desired. OpenSSL 0.9.8o enables the SHA-2 hash algorithms in the default configuration.

Database Support  

* The pgcrypto module for PostgreSQL introduced support for the SHA-2 family of hash algorithms with the 8.1 release but only for the standalone module. 8.2 incorporated the SHA-2 functions of the pgcrypto module into PostgreSQL core allowing these hashes to be available to PostgreSQL even if the installed version of OpenSSL does not support it.

Detailed Operating System Support  

Notes on «Partial» compatibility:
* S/MIME:

• Outlook on Windows XP SP3 can utilize certificates signed with SHA-256 but cannot validate an e-mail signed using the SHA-256 hashing algorithm.
• By default Outlook signs with SHA1 even if a SHA2 cert is in use though this behavior can be changed if desired.

** Code Signing:

• Code can be signed with a SHA2 cert on any of the systems listed as having partial or full compatibility without issue.
• There is an incompatibility with SHA2 signed kernel drivers on the partially compatible platforms. Kernel drivers signed with SHA2 certs will not install on systems listed as having «Partial» compatibility.

E-Mail Clients

The signature hash algorithm on the certificate itself is independent of the signature hash placed on an e-mail. For example, Outlook 2003 on XP SP3 can utilize a certificate signed with SHA-256 to sign an encrypt e-mails. But the signature on the e-mail will be limited to SHA1.

Set Outlook Hash Algorithm to SHA-1

Outlook 2003: Tools > Options > Settings > Security > Settings > Hash Algorithm > SHA1

Outlook 2007, 2010, 2013: File > Options > Trust Center > Trust Center Settings > E-Mail Security > Settings > Hash Algorithm > SHA1

Document Signing

Windows Code Signing  

  SafeNet iKey / eToken Compatibility

Mainframe 

Citrix Support

Sources:

[1] SHA2 and Windows.
[2] Common questions about SHA2 and Windows.
[3] OpenSSL 0.9.8 Branch Release notes
[4] Bug 222179 — User preferences should control ciphers used when sending encrypted S/MIME messages
[5] iKey 4000 Specifications
[6] eToken 5100 Specifications
[7] Verified In-House
[8] IBM Notes SHA2 Support
[9] IBM Domino Planned SHA-2 Support
[10] IBM HTTP Server
[11] IBM z/OS
[12] GnuTLS
[13] .NET Security Blog
[14] Security Advisory 2949927 (SHA-2 Hash Support for Kernel Drivers — Currently Retracted)
[15] SHA-2 Signed Executables Windows Vista & Server 2008
[16] VSTO Runtime Update to Address “Unknown Publisher” for SHA256 Certificates
[17] Digital Certificate Requirements (Technet)
[18] Mozilla NSS 3.8 Release Notes
[19] Java 1.4.2 Release Notes
[20] Availability of SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2
[21] Add recognition of SHA-2 hashes when verifying S/MIME messages
[22] Thunderbird 38 Release Notes
[23] MYSQL 5.5 Release Notes
[24] PostgreSQL 8.1 Release Notes
[25] PostgreSQL 8.2 Release Notes
[26] PM62842: Web Services Security Runtime Update to Support SHA-2 Signature Algorithms
[27] Oracle Weblogic — Configuring SSL
[28] Certificate Requirements for Federation Servers
[29] Release Notes for the Cisco ASA 5500
[30] App Transport Security Technot

PROBLEM: Unable to validate Digital Signature on Windows XP SP3

I recently encountered the following errors when attempting to validate the Digital Signatures for our application on Windows XP SP3:

Digital Code Signature (Right-click application > Properties > Digital Signatures > Details)

Digital Signature Information
The certificate is not valid for the requested usage.

Certificate Information
This certificate does not appear to be valid for the selected purpose.

Receiving these same errors? If your code signing certificate was issued in the past 24 hours, you might just need to wait a day before Windows XP SP3 can validate the signature. See solution #2 at the end of this article for details.

I was attempting to use the following widely-accepted signtool.exe commands to perform Dual Code Signing (SHA-1 and SHA-2/SHA-256 file digest algorithms) of an Executable for use with current systems (e.g. Windows 7, Windows 8, Windows 10) as well as legacy systems (Windows XP SP3, Windows Vista).

Note: As of 03/2018, every one of these OS should accept a “User Mode” executable (e.g. application or service) that is signed with an SHA-1 file digest algorithm. We would like to dual sign to “future proof” our executables since we anticipate that some of these OS will eventually require an SHA-256 file digest algorithm.

signtool.exe sign /f comodo256.pfx /p password /t http://timestamp.comodoca.com /v app.exe
signtool.exe sign /f comodo256.pfx /p password /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /as /v app.exe

We are using our new Comodo SHA-256 code signing certificate with the COMODO SHA-1 Time Stamping server and the COMODO SHA-256 Time Stamping server.

The first command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-1 file digest and a timestamp counter-signature with an RSA SHA-1 file digest. *

The second command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-256 file digest and a timestamp counter-signature with an RSA SHA-256 file digest.

* Contrary to code signing documentation on several certificate authority websites, we have found that XP SP3 *CAN* validate a digital signature when signed with an RSA SHA-256 code signing certificate, as long as the actual signature uses an RSA SHA-1 file digest algorithm.

TROUBLESHOOTING NOTES

I attempted several variations of the signtool.exe commands above. I also attempted using the ZIP bundle of “signtool.exe” version 8.1 distributed by K-Software as well as the “kSign” software created by K-Software to dual sign several executables. I continued to receive the exact same errors, which led me to believe there may be a problem with my certificate, or it was no longer possible to dual sign for XP SP3.

While researching these two digital signature validation errors on Windows XP SP3, I could find no mention of the errors I encountered above related to code signing on legacy systems. In addition, the discussion surrounding SHA-1 vs SHA-256 and the Microsoft announcement to no longer support code signing with SHA-1 made it difficult to determine if it was still possible to dual sign executables with support for legacy systems that require SHA-1.

Through trial and error, I realized that Microsoft no longer allows digital signatures based on RSA SHA-1 digital certificates, but every OS from Windows XP SP3 to Windows 10 continue to support “User Mode” executable (e.g. application or service) that are signed with an RSA SHA-1 file digest algorithm. This Windows Code Signing Hash Algorithm Support article from GlobalSign has a nice chart that supports these findings. The distinction here is that the digital certificate is used to sign all of your applications, whereas the file digest algorithm is the format of the file hash output that is embedded in the executable. I suppose it may be worthwhile for someone to forge a certificate (that could sign many applications), but it would not be as likely or worthwhile for someone to forge an individual signature.

SOLUTION #1: Dual Sign with “osslsigncode” on Linux/OSX instead of “signtool.exe” on Windows

Thanks to a response from @Keeely in the thread signtool failing to dual sign SHA2 and SHA1 with timestamps, I was able to use our Comodo SHA-256 code signing certificate to dual sign an application that validates correctly on Windows XP SP3. I adapted his SHA1-only solution to successfully dual sign with SHA-1 and SHA-2/SHA-256.

Digital Code Signature (Right-click application > Properties > Digital Signatures > Details)

This digital signature is OK
This certificate is intended for the following purpose(s):
Ensures software came from software publisher
Protects software from alteration after publication

Digital Timestamp Counter-Signature

This digital signature is OK
This certificate is intended for the following purpose(s):
Allows data to be signed with the current time

I had to install osslsigncode, which is designed for Linux and also available on OSX. A fork also appears to be available for Windows.

osslsigncode sign -pkcs12 comodo256.pfx -pass password -h sha1 -t http://timestamp.comodoca.com -in unsigned.exe -out intermediate.exe
osslsigncode sign -pkcs12 comodo256.pfx -pass password -nest -h sha256 -ts http://timestamp.comodoca.com/?td=sha256 -in intermediate.exe -out signed.exe

The first command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-1 file digest and a timestamp counter-signature with an RSA SHA-1 file digest into a new file named “intermediate.exe”, which you would delete afterwards.

The second command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-256 file digest and a timestamp counter-signature with an RSA SHA-256 file digest into a new file named “signed.exe”, which you would distribute to your end users.

SOLUTION #2 – Dual Sign with native Windows tools?

Wait several days?

The certificate was issued on a Friday morning. I was attempting to sign executables with our new certificate that same day. When I revisited this issue on Monday, I realized that XP SP3 was suddenly able to validate the previous signatures that were applied with the “signtool.exe” commands listed above.

Windows Registry Editor Version 5.00 
[HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady] 
"Installed"=dword:00000001

CryptAcquireContext 75 TRUE: 0
CryptAcquireContext 80 TRUE: 0
CryptAcquireContext 81 TRUE: 0

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

First published on TECHNET on Sep 30, 2010

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

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.

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

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.

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.

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.

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.

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.

-Adam Stasiniewicz

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

Starting from Windows XP SP3 there is a partial support for SHA256.

With CryptoAPI when calling the «CryptCreateHash» function, it is important to choose a provider that supports it. 

Microsoft basic or enhanced cryptographic providers will not work for this case, use 

«Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)»  instead.

This provider in Windows Vista and above supports SHA512 as well — great thing for testing, since all smart card manufacturers do this.

Unfortunately Microsoft does not support the SHA256RSA in .NET frameworks so far, SignedCms will tell it doesn’t recognize this algorithm.

There are some implementations of pkcs7 encoding with SHA256RSA that work on windows XP SP3 — they are not free, but they do exist. 
For instance ComsignTrustDesktop implements pkcs7 encoding with SHA256RSA for any type of files. There are some further difficulties with it such a lack of support from Microsoft Office 2007-20010 which do not support signature validation of this kind. 

For further details please refer to :

Here is a PFX I’ve prepared for testing purposes: