Digital signature timestamp "not available" on XP/Vista, causing verification failure

Question

Background

I have a WiX/Burn installation bundle which, among other things, installs the ReportViewer 2012 Runtime. When run on a Windows 7 or later machine, it works fine. On XP (SP3) or Vista (SP1) it fails.

Now, checking the download page for the ReportViewer redistributable, I do notice it says it requires Vista SP2 or higher. Normally I would accept this, but a)I think this has recently changed, and b)downloading and manually installing this redistributable works. It's possible there are parts that do not work on XP/Vista but for my intents and purposes it installs and runs quite well despite their claims.

Problem

Examining the installation log file explains the digital signature verification failed. So I manually download the redistributable package onto the Windows XP machine and examine its signature. The signature is there, but the timestamp reports "Not available". Hitting Details also tells me the signing time is "Not available". The file itself is signed by an expired certificate, so naturally verification fails without this timestamp.

However, if I download the same file to a Windows 7 machine, the timestamp is present. Hitting Details shows me the countersignature, verification works, and installation proceeds correctly.

What I've Tried

I have installed a number of different versions of the "Update for Root Certificates" to no avail, including the latest. If this is indeed the solution, please tell me which one I need.

I have followed the certificate chain on the countersignature and it ends at "Microsoft Root Certificate Authority 2010". This root certificate appears to be installed in the XP machine. The only thing I can see is the "2011" version of this certificate is also in the "Third-Party Root Certification Authorities" store, while the 2010 is not. I do not know if this is the cause of the problem or normal.

I may eventually resort to disabling signature verification and using hash-based verification of the payload. However before doing this I would like to know if I have missed something obvious.

My Question

Is there an update to download or a step that can be taken by "normal" users which will allow the timestamp/countersignature to be recognized in XP/Vista? "Normal" users here means someone who is not very computer-literate; I am not referring to administrator rights.

Tympanitis

Answer 1

It seems that there are two timestamp countersignature types that can be used for Windows code signing (Authenticode):

• Proprietary: results in V1 in the Version field (PKCS#7 version?) of the countersignature properties
• RFC 3161 based: results in V2

I have not found any documentation that states this explicitly, but through testing it seems that Windows XP (SP3, with all updates installed) only supports timestamps with version V1. Timestamps with version V2 result in the "not available" status. Of course, the version numbers might just correlate with the results -- there is possibly another aspect to the timestamp that causes it to be ignored.

The ReportViewer MSI file that is currently available has a V2 timestamp. However, the timestamp was also made in July 2014, after this question was posted.

More background:

The Windows SDK signtool command supports two options (to the sign and timestamp sub-commands) to generate the two different timestamp types:

• /t <timestamp server URL>: results in V1
• /tr <RFC 3161 timestamp server URL>: results in V2

The signtool documentation for /tr states:

Windows Vista and earlier: This flag is not supported.

However, it seems unclear (due to the way that similar statements are used on other options) whether this applies to the target system or the system that signtool is running on.

Examples

V1 timestamp:

signtool.exe sign /f cert.pfx /p %passphrase% /t http://timestamp.comodoca.com/authenticode /d "Test" test.exe

V2 timestamp:

signtool.exe sign /f cert.pfx /p %passphrase% /tr http://timestamp.comodoca.com/rfc3161 /d "Test" test-rfc3161.exe

Loadstone

I can verify that switching from /tr to /t caused windows Vista to start recognizing timestamps on my signatures. I even tried downloading an executable signed with /t in IE 10 on Windows 7 64-bit, and it worked fine, despite it not working for me in the past. (I used to think that IE scans files signed with /t and says they are invalid, and I can still reproduce that with some old files I signed on one particular system.) But whether I use /t or /tr, the timestamp shows up as "V2" in the Properties dialog. I think the version number is not important like you say it is. – Prochoras

I was using GlobalSign's timestamp server; I didn't try comodoca, and that could explain the differences. I still agree that /t fixes the problem, but I think the V1/V2 thing you observed is just a coincidence. – Prochoras

Thanks @DavidGrayson. I agree that the V1/V2 thing is likely a coincidence. – Loadstone

Answer 2

Hard to say exactly, but it looks like this may be related to http://technet.microsoft.com/en-us/security/advisory/2749655

Per RFC3280, timestamp Enhanced Key Usage (EKU) extensions are used to bind the hash of an object to a time. These signed statements show that a signature existed at a particular point in time. They are used in code integrity situations when the code signing certificate has expired, to verify that the signature was made before the certificate expired. This issue is caused by a missing timestamp Enhanced Key Usage (EKU) extension during certificate generation and signing of Microsoft core components and software. Some certificates used for two months of 2012 did not contain an X.509 timestamp Enhanced Key Usage (EKU) extension.

I would not be surprised an error like "timestamp not available" would be given even if the signature includes a timestamp when the certificate does not contain a timestamp EKU, because at a certain level that is the case and error messages often lack this sort of detail.

Have you applied the updates from http://support.microsoft.com/kb/2749655 ?

What does this update do?

This update will help to ensure the continued functionality of all software that was signed with a specific certificate that did not use a timestamp Enhanced Key Usage (EKU) extension. To extend their functionality, WinVerifyTrust will ignore the lack of a timestamp EKU for these specific X.509 signatures

Opportunity

Thank you for your answer. I'm not sure how relevant it is to this particular case though. I've already tried the update you linked to and it does not fix the problem. And, FWIW, looking at the countersigning certificate on a Windows 7 machine where it is recognized and shows up, it (Microsoft Time-Stamp Service) does have a Timestamping EKU extension (1.3.6.1.5.5.7.3.8) specified. – Tympanitis

Yes, of course it makes sense that the install would work where the countersigning certificate has a Timestamping EKU extension specified. It's possible that the developer didn't include a timestamp for the older certificate at generation time because the signing tool respected the (lack of) Timestamping EKU in the relevant certificate, in which case your only hope would be to install the Windows 7 certificate, which is beyond my expertise to know if it is even feasible. – Opportunity