Code Signing errors when Dual Signing SHA-1 and SHA-256 for Legacy Systems including Windows XP SP3

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.

Leave a Reply

Your email address will not be published. Required fields are marked *