Windows 10会忽略我的设置文件上的Authenticode [英] Windows 10 ignores Authenticode on my setups files

问题描述

在Windows 10的快速环"上，我在自己的安装可执行文件上出现了奇怪的行为:

我正在SHA-1上用 Authenticode 多年来一直以相同的方式进行，从来没有任何问题.

最近Windows 10无法识别我的(有效)签名.

从我的网站下载setup.exe并执行它时，出现Windows SmartScreen消息框并告诉我:

...
发布者:unknown
...

查看刚刚下载的安装可执行文件的属性时，它会显示签名，并告诉我该签名是有效的.

此外，整个证书链都是有效的.

我正在使用类似这样的签名:

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

(添加了换行符以提高可读性)

我的问题:

有人知道这个可能的原因(和解决方法)吗?

更多信息:

我可以想到可能的原因:

• 使用Windows 10 Fast Ring签名是错误的. (我已经以相同的方式在Windows Server 2008 R2上签名了.)
• 在Windows 10 Fast Ring中运行下载的安装可执行文件存在错误.

更新1:

我发现 2013年以来的MSDN博客文章，似乎在谈论类似的事情，但我发现我仍然看不到这是否真的适用.

更奇怪:使用相同的Authenticode证书签名的较早版本从我们的网站上下载，不会触发警告.

也许SmartScreen对时间戳进行比较，并且对于较新的签名/设置可执行文件的行为有所不同?

也许在调用SignTool.exe时需要添加其他/不同的参数?

更新2:

在非Fast Ring Windows 10上，不会显示 SmartScreen警告.

此外，也有类似的SO发布信息，对我没有进一步的帮助.

加上

这对我来说很奇怪，因为我的签名过程一直成功进行到最近.

他们进一步 GSerg指出我要"这似乎朝着正确的方向前进.

我已经看到我当前的证书是SHA-1.我刚刚从Thawte重新发行，将其更新为SHA-2/SHA-256.

现在，我仍然在本地Windows 10 Fast Ring PC上收到SmartScreen警告，但至少现在它可以打印发布者了.

我不会从DigiCert购买代码签名证书因为我相信证书链也会影响SmartScreen筛选器如何看待我的应用程序.我确实希望，与我目前使用的Thawte证书相比，这是一个改进.

如果您打算登录Windows Vista，请注意出现问题SHA-256签名文件.链接的TechNet文章讨论了此SO答案，该问题与通过已签名的应用程序传递SmartScreen警告有关.

如果此DigiCert证书加上等待获得足够的声誉仍然没有帮助，我可能不得不吞下苦药并购买

我本以为这仍然会引起SmartScreen的担忧，但似乎没有.

更新6:

文章"您需要SHA-2签名的根证书吗? ?"解释了为什么您不需要需要SHA-256根证书.

同时，我还获得了DigiCert的Authenticode证书.我已经在某些设置中使用它了.

只花了一天的时间，直到SmartScreen过滤器将其捡起并不再对其进行警告.

所以我现在拥有Thawte Authenticode代码签名证书和DigiCert Authenticode代码签名证书.

如果我较早理解SHA-256的含义，我本可以为DigiCert证书省钱.

解决方案

为

使用SHA-1和SHA-256对我的安装可执行文件进行双重签名(并等待几天)后，SmartScreen筛选器不再抱怨.

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.

解决方案

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.

这篇关于Windows 10会忽略我的设置文件上的Authenticode的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！