IE says my signed game installer is reported as harmful.

Question

How do I dispute this false alarm?

This happens after the executable is downloaded. There is no way to actually run the installer, and it does not appear in downloads. The software is correctly signed with our signature, and no Microsoft representative has contacted us about this happening.

Microsoft Security Essentials correctly detects nothing wrong with the installer.

This is a game completely developed inhouse, there is no harmful software included (as long as spending time in a racing game is not considered harmful).

This is a critical issue for our company. I asked this question originally at the IE forums ( http://answers.microsoft.com/en-us/ie/forum/ie9-windows_7/ie-says-my-signed-game-installer-is-reported-as/05df6829-deca-48b7-bfdf-35d6bfd06778 ), but I was asked to as the question here instead.

Answer 1

this forum is for html, css, js

Answer 2

all low volume exe downloads receive the prompt.....

either

package it in a zip

or

users can over-ride the "Cannot download this type of file" by clicking the Advanced link on the download dialog.

or

Undertake the Made for windows certification

to have your company recognised as a high volume download go to support.microsoft.com and locate your local MS office to make enquiries there..I think.. I will check if that is the proceedure..... my guess is that you will require Windows certification.

---

Rob^_^

fab is right.... but I saw your post at the other forum... ok

Answer 3

That is right, this has nothing to do with web development.

So the guess at the moment is that the behaviour is triggered by an expired timestamp signature in the executable (the executable was signed with a timestamp from verisign, that had expiration date at 2012-06-15).

That the executable signature would be deemed invalid/tampered/expired for this, seems to me like a bug, as the timestamps are added exactly for the purpose of making the signature not expire when used (as it is known to have been signed when the signature was valid).

Anyway, after spending long hours tracking one, I got a direct contact from Microsoft without the price sticker, so I have full confidence eventually whatever is broken will heal.

Answer 4

ok...

sounds like your good for the moment and are on track for a resolution. MSFT asked for a link, but since you have already made contact I suppose no further action is required here?

Regards.

---

Rob^_^

Answer 5

An example conflicting installer can be downloaded from http://superstarracing.net/WT/ML_USA2/Superstar%20Racing.exe

If someone can do something, or find something more about the issue, all the better. As it stands now, all of our more popular installers are re-signed, so they work fine.

Answer 6

Hi,

thanks for the link... I have passed it on..but I cannot guarantee a response... It will depend apon their workload and timelines....

fyi: all feedback and bug reports should be posted to http://connect.microsoft.com/ie (unfortunately they are only accepting IE10 feedback at the moment)...

you may like to browse the IE Internals blog for any relavent information about Ie's software Authenticode behavior...

http://blogs.msdn.com/b/ieinternals/archive/2012/06/13/windows-internet-explorer-block-rsa-key-shorter-than-1024-bits.aspx

---

Rob^_^

Answer 7

The problem here is that your StartCOM certificate contains the Lifetime Signing OID. That OID means that when the certificate expires, the signature is invalid, regardless of whether or not the package was properly timestamped.

I wrote about this here.

Not all publisher certificates are enabled to permit timestamping to provide indefinite lifetime. If the publisher’s signing certificate contains the lifetime signer OID (szOID_KP_LIFETIME_SIGNING 1.3.6.1.4.1.311.10.3.13), the signature becomes invalid when the publisher’s signing certificate expires, even if the signature is timestamped. This is to free a Certificate Authority from the burden of maintaining Revocation lists (CRL, OCSP) in perpetuity.

Answer 8

That is probably a technically correct description of what should happen.

However, in this case, the expired signature was the signature used by the timestamping service from verisign. The actual executable signature was and is still valid. It still seems to be that this is a bug in IE, and the expiration of the timestamp signature should not invalidate the executable signature, which is valid until the start of 2013 (the combined signature stopped being valid at 2012-06-15 in IE, at which time the timestamp signature expired).