title: Windows 10 ignores Authenticode on my setups files
body: <p>Being on the "Fast Ring" of Windows 10, I got a strange behaviour on my own setup executables:</p>
  
  <p>I'm SHA-1 signing them with <a href="https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx" rel="nofollow noreferrer">Authenticode</a> since years the same way and never had any problems. </p>
  
  <p>Recently Windows 10 does not recognize my (valid) signatures.</p>
  
  <p>When downloading a setup.exe from my website and executing it, the Windows SmartScreen message box appears and tells me:</p>
  
  <blockquote>
    <p>...<br>
    Publisher: unknown<br>
    ...</p>
  </blockquote>
  
  <p>When viewing the properties of the just downloaded setup executable, it shows the signature, and tells me that the signature is valid.</p>
  
  <p>In addition, the whole certificate chain is valid.</p>
  
  <p>I'm signing it with something like this:</p>
  
  <pre><code>SignTool.exe sign /v /t http://timestamp.verisign.com/scripts/timstamp.dll 
      /f "my-authenticode.pfx" /p "my-password" "my-setup.exe"
  </code></pre>
  
  <p>(Line-breaks added for readability)</p>
  
  <p><strong>My question:</strong></p>
  
  <p>Is anyone aware of a possible reason (and fix) for this?</p>
  
  <p><strong>More Information</strong>:</p>
  
  <p>I can think of possible reasons:</p>
  
  <ul>
  <li><strike>Signing with Windows 10 Fast Ring is buggy</strike>. (I've signed on Windows Server 2008 R2 with the same behaviour).</li>
  <li>Running the downloaded setup executable within Windows 10 Fast Ring is buggy.</li>
  </ul>
  
  <p><strong>Update 1:</strong></p>
  
  <p>I've found <a href="http://blogs.msdn.com/b/vsnetsetup/archive/2013/01/09/windows-smartscreen-prevented-an-unrecognized-app-from-running-running-this-app-might-put-your-pc-at-risk.aspx" rel="nofollow noreferrer">a MSDN blog article back from 2013 that seems to talk about something similar</a> as I discover, but I still cannot see whether this really applies.</p>
  
  <p>More strange: Older downloads from our website, signed with the same Authenticode certificate do <em>not</em> trigger the warning.</p>
  
  <p>Maybe SmartScreen compares the timestamp and behaves differently for newer signatures/setup executables?</p>
  
  <p>Maybe I would need to add additional/different parameters when calling SignTool.exe?</p>
  
  <p><strong>Update 2:</strong></p>
  
  <p>On a non-Fast Ring Windows 10, the SmartScreen warning is <em>not</em> displayed.</p>
  
  <p>In addition, <a href="https://stackoverflow.com/q/25163521/107625">there is also a similar SO posting</a> which didn't help me further.</p>
  
  <p>Plus, <a href="https://knowledge.symantec.com/support/code-signing-support/index?page=content&amp;id=INFO190&amp;actp=LIST&amp;viewlocale=en_US" rel="nofollow noreferrer">there is a Symantec posting, that claims</a>:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>This is strange to me since my signing procedure worked successfully until recently.</p>
  
  <p>They further <a href="https://knowledge.symantec.com/support/code-signing-support/index?page=content&amp;id=SO5820&amp;actp=search&amp;viewlocale=en_US" rel="nofollow noreferrer">link to their own instructions</a> which talk about kernel mode software only.</p>
  
  <p><strong>Update 3:</strong></p>
  
  <p>User <a href="https://stackoverflow.com/questions/34979463/windows-10-ignores-authenticode-on-my-setups-files?noredirect=1#comment57689736_34979463">GSerg pointed</a> me to "<a href="http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx" rel="nofollow noreferrer">Windows Enforcement of Authenticode Code Signing and Timestamping</a>" on Microsoft TechNet.</p>
  
  <p>This seems to go into the right direction.</p>
  
  <p>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.</p>
  
  <p>Now, I still get a SmartScreen warning on my local Windows 10 Fast Ring PC but at least it now prints the publisher.</p>
  
  <p><a href="https://i.stack.imgur.com/s3sU1.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/s3sU1.png" alt="enter image description here"></a></p>
  
  <p>I'll no purchase a <a href="https://www.digicert.com/code-signing/code-signing.htm" rel="nofollow noreferrer">code signing cert from DigiCert</a> 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.</p>
  
  <p>If you plan to sign for Windows Vista, please note that there <a href="https://support.microsoft.com/de-de/kb/2763674" rel="nofollow noreferrer">was a problem with SHA-256 signed files</a>. The linked TechNet article talks about <a href="http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#How_to_dual_sign_files" rel="nofollow noreferrer">dual signing</a> to overcome this.</p>
  
  <p><strong>Update 4:</strong></p>
  
  <p>See also <a href="https://stackoverflow.com/a/28359323/107625">this SO answer</a> that deals about passing the SmartScreen warning with signed applications.</p>
  
  <p>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 <a href="https://www.digicert.com/code-signing/ev-code-signing.htm" rel="nofollow noreferrer">extended validation (EV) code signing certificate</a> (which requires a hardware token and is more expensive).</p>
  
  <p><strong>Update 5:</strong></p>
  
  <p>After approx. one day, SmartScreen seems to <em>not</em> show any warnings anymore.</p>
  
  <p>Seems that my now dual-signed setup executables (SHA-1 plus SHA-256) already got enough reputation to successfully pass the SmartScreen tests.</p>
  
  <p><a href="https://i.stack.imgur.com/kr1oE.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/kr1oE.png" alt="enter image description here"></a></p>
  
  <p>My certification path/chain now looks like this:</p>
  
  <p><a href="https://i.stack.imgur.com/0qenX.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/0qenX.png" alt="enter image description here"></a></p>
  
  <p>What looks a bit strange to me is that the root certificate "thawte" still uses SHA-1. </p>
  
  <p>I would have expected that this still causes SmartScreen worries, but it seems it doesn't.</p>
  
  <p><strong>Update 6:</strong></p>
  
  <p>The article "<a href="https://www.entrust.com/need-sha-2-signed-root-certificates/" rel="nofollow noreferrer">Do You Need SHA-2 Signed Root Certificates?</a>" explains why you do <em>not</em> need a SHA-256 root certificate.</p>
  
  <p>In the meantime I've also received my Authenticode certificate from DigiCert. I'm using it in some setups already.</p>
  
  <p>It only took about one single day until the SmartScreen filter did pick it up and <em>not</em> warn about it anymore.</p>
  
  <p>So I'm now having a Thawte Authenticode code signing certificate and a DigiCert Authenticode code signing certificate.</p>
  
  <p>If I understood the SHA-256 implications earlier, I could have saved the money for the DigiCert certificate.</p>