being on "fast ring" of windows 10, got strange behaviour on own setup executables:
i'm sha-1 signing them authenticode since years same way , never had problems.
recently windows 10 not recognize (valid) signatures.
when downloading setup.exe website , executing it, windows smartscreen message box appears , tells me:
...
publisher: unknown
...
when viewing properties of downloaded setup executable, shows signature, , tells me signature valid.
in addition, whole certificate chain valid.
i'm signing 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 readability)
my question:
is aware of possible reason (and fix) this?
more information:
i can think of possible reasons:
signing windows 10 fast ring buggy. (i've signed on windows server 2008 r2 same behaviour).- running downloaded setup executable within windows 10 fast ring buggy.
update 1:
i've found a msdn blog article 2013 seems talk similar discover, still cannot see whether applies.
more strange: older downloads our website, signed same authenticode certificate not trigger warning.
maybe smartscreen compares timestamp , behaves differently newer signatures/setup executables?
maybe need add additional/different parameters when calling signtool.exe?
update 2:
on non-fast ring windows 10, smartscreen warning not displayed.
in addition, there similar posting didn't me further.
plus, there symantec posting, claims:
for windows vista 64-bit , windows 7 signing process has changed. code cannot signed, needs "cross-signed" certificate provided microsoft.
this strange me since signing procedure worked until recently.
they further link own instructions talk kernel mode software only.
update 3:
user gserg pointed me "windows enforcement of authenticode code signing , timestamping" on microsoft technet.
this seems go right direction.
i've seen current certificate sha-1. i've updated sha-2/sha-256 re-issuing thawte.
now, still smartscreen warning on local windows 10 fast ring pc @ least prints publisher.
i'll no purchase code signing cert digicert since believe certificate chain has influence on how smartscreen filter sees application. hope improvement compared thawte certificate i'm using.
if plan sign windows vista, please note there was problem sha-256 signed files. linked technet article talks dual signing overcome this.
update 4:
see this answer deals passing smartscreen warning signed applications.
if digicert certificate plus waiting enough reputation still not help, i'll have swallow bitter pill , buy extended validation (ev) code signing certificate (which requires hardware token , more expensive).
update 5:
after approx. 1 day, smartscreen seems not show warnings anymore.
seems dual-signed setup executables (sha-1 plus sha-256) got enough reputation pass smartscreen tests.
my certification path/chain looks this:
what looks bit strange me root certificate "thawte" still uses sha-1.
i have expected still causes smartscreen worries, seems doesn't.
update 6:
the article "do need sha-2 signed root certificates?" explains why not need sha-256 root certificate.
in meantime i've received authenticode certificate digicert. i'm using in setups already.
it took 1 single day until smartscreen filter did pick , not warn anymore.
so i'm having thawte authenticode code signing certificate , digicert authenticode code signing certificate.
if understood sha-256 implications earlier, have saved money digicert certificate.
as user gserg pointed out, reason error in initial question i'm using sha-1 "deprecated" microsoft since 2016.
after dual-signing setup executable both sha-1 , sha-256 (and waiting days), smartscreen filter not complain anymore.
Comments
Post a Comment