Digital Signature Timestamp “Unavailable” in XP / Vista, Verification Fails

Question

Background

I have a WiX / Burn installation package that, among other things, sets the runtime of ReportViewer 2012. When it runs on Windows 7 or later, it works fine. In XP (SP3) or Vista (SP1) it does not work.

Now, while checking the download page for the redistributed ReportViewer , I notice that it requires Vista SP2 or higher. I usually agree with this, but a) I think this has recently changed, and b) download and manually install these redistributable works. There may be parts that do not work on XP / Vista, but for my purposes and tasks it installs and works pretty well, despite their requirements.

Problem

Examining the installation log file explains that the digital signature verification failed. Therefore, I manually download the redistributable package to a computer running Windows XP and verify its signature. There is a signature, but the timestamp says "Not Available". The percussion data also tells me that the signature time is "Not Available". The file itself is signed with an expired certificate, so the natural verification completes without this timestamp.

However, if I upload the same file to a Windows 7 machine, a timestamp is present. Impact details show that signature, verification, and installation are progressing correctly.

What i tried

I installed several different versions of “Upgrade for root certificates” to no avail, including the latest . If this is really a solution, tell me which one I need .

I followed the chain of certificates on the counter, and ends with "Microsoft Root Certificate Authority 2010". This root certificate appears on the XP computer. The only thing I see is the "2011" version of this certificate is also located in the "Third-Party Root Certification Authorities" store, but 2010 is not. I do not know if this is the cause of the problem or normal.

Ultimately, I can resort to disabling signature verification and using validation based on payload hashes. However, before that, I would like to know if I missed something obvious.

My question

Is there an update to download, or a step that "regular" users can take to recognize the time stamp / counter in XP / Vista? “Normal” users here mean someone who is not very computer literate; I do not mean administrator rights.

Answer 1

There seem to be two types of timestamp labels that can be used to sign Windows code (Authenticode):

• Ownership : results in V1 in the Version field (PKCS # 7 version?) Of counter properties
• RFC 3161: V2 Results

I did not find the documentation that stated 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 an unreachable state. Of course, version numbers can simply correlate with the results - perhaps there is another aspect of the timestamp that makes it ignore.

The currently available MSI ReportViewer file has a V2 timestamp. However, a time stamp was also made in July 2014 after the publication of this issue.

More background:

The signtool Windows SDK signtool supports two parameters ( sign and timestamp subcommands) to generate two different types of timestamps:

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

The signtool documentation for /tr states:

Windows Vista and earlier: This flag is not supported.

However, this seems unclear (due to the fact that similar operators are used for other parameters) whether this applies to the target system or the system on which signtool is signtool .

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 

Answer 2

It's hard to say for sure, but it looks like it could be related to http://technet.microsoft.com/en-us/security/advisory/2749655

In RFC3280, timestamps The Extended Key Extension (EKU) is used to bind the hash of an object to time. These signed statements indicate that the signature existed at a particular point in time. They are used in code integrity situations when the code signing certificate has expired to make sure that the signature was made before the certificate expired. This problem is caused by the lack of a time reference for the extended key extension (EKU) during the creation of the certificate and the signing of the main components and software of Microsoft. Some certificates used during the two months of 2012 did not contain the X.509 Extended Key Extension (EKU).

I would not be surprised that an error such as "timestamp not available" will be provided even if the signature contains a timestamp when the certificate does not contain an EKU timestamp, because at a certain level that takes place and error messages are often missing such kind of details.

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

What does this update do?

This update will help ensure the continued functionality of all software that has been signed with a specific certificate that has not used an extended key extension (EKU) with a time stamp. To expand their functionality, WinVerifyTrust will ignore the lack of EKU timestamps for these specific X.509 signatures