Windows 10 ignores Authenticode on my setups files

Question

Being on the "Fast Ring" of Windows 10, I got a strange behaviour on my own setup executables:

I'm SHA-1 signing them with Authenticode since years the same way and never had any problems.

Recently Windows 10 does not recognize my (valid) signatures.

When downloading a setup.exe from my website and executing it, the Windows SmartScreen message box appears and tells me:

...
Publisher: unknown
...

When viewing the properties of the just downloaded setup executable, it shows the signature, and tells me that the signature is valid.

In addition, the whole certificate chain is valid.

I'm signing it with something like this:

SignTool.exe sign /v /t http://timestamp.verisign.com/scripts/timstamp.dll 
    /f "my-authenticode.pfx" /p "my-password" "my-setup.exe"

(Line-breaks added for readability)

My question:

Is anyone aware of a possible reason (and fix) for this?

More Information:

I can think of possible reasons:

• Signing with Windows 10 Fast Ring is buggy. (I've signed on Windows Server 2008 R2 with the same behaviour).
• Running the downloaded setup executable within Windows 10 Fast Ring is buggy.

Update 1:

I've found a MSDN blog article back from 2013 that seems to talk about something similar as I discover, but I still cannot see whether this really applies.

More strange: Older downloads from our website, signed with the same Authenticode certificate do not trigger the warning.

Maybe SmartScreen compares the timestamp and behaves differently for newer signatures/setup executables?

Maybe I would need to add additional/different parameters when calling SignTool.exe?

Update 2:

On a non-Fast Ring Windows 10, the SmartScreen warning is not displayed.

In addition, there is also a similar SO posting which didn't help me further.

Plus, there is a Symantec posting, that claims:

For Windows Vista 64-bit and Windows 7 the signing process has changed. The code cannot simply be signed, it also needs to be "cross-signed" with a certificate provided by Microsoft.

This is strange to me since my signing procedure worked successfully until recently.

They further link to their own instructions which talk about kernel mode software only.

Update 3:

User GSerg pointed me to "Windows Enforcement of Authenticode Code Signing and Timestamping" on Microsoft TechNet.

This seems to go into the right direction.

I've seen that my current certificate is SHA-1. I've just updated it to SHA-2/SHA-256 by re-issuing it from Thawte.

Now, I still get a SmartScreen warning on my local Windows 10 Fast Ring PC but at least it now prints the publisher.

I'll no purchase a code signing cert from DigiCert since I believe that the certificate chain also has influence on how the SmartScreen filter sees my application. I do hope it is an improvement compared to the Thawte certificate I'm currently using.

If you plan to sign for Windows Vista, please note that there was a problem with SHA-256 signed files. The linked TechNet article talks about dual signing to overcome this.

Update 4:

See also this SO answer that deals about passing the SmartScreen warning with signed applications.

If this DigiCert certificate plus waiting to get enough reputation still does not help, I'll probably have to swallow the bitter pill and buy an extended validation (EV) code signing certificate (which requires a hardware token and is more expensive).

Update 5:

After approx. one day, SmartScreen seems to not show any warnings anymore.

Seems that my now dual-signed setup executables (SHA-1 plus SHA-256) already got enough reputation to successfully pass the SmartScreen tests.

My certification path/chain now looks like this:

What looks a bit strange to me is that the root certificate "thawte" still uses SHA-1.

I would have expected that this still causes SmartScreen worries, but it seems it doesn't.

Update 6:

The article "Do You Need SHA-2 Signed Root Certificates?" explains why you do not need a SHA-256 root certificate.

In the meantime I've also received my Authenticode certificate from DigiCert. I'm using it in some setups already.

It only took about one single day until the SmartScreen filter did pick it up and not warn about it anymore.

So I'm now having a Thawte Authenticode code signing certificate and a DigiCert Authenticode code signing certificate.

If I understood the SHA-256 implications earlier, I could have saved the money for the DigiCert certificate.

Answer 1

As user GSerg pointed out, the reason for the error in my initial question was that I'm using SHA-1 only which is "deprecated" by Microsoft since 2016.

After dual-signing my setup executable both with SHA-1 and SHA-256 (and waiting some days), the SmartScreen filter does not complain anymore.