My company distributes an installer to customers via our website. Recently when I download via the website and try to run the installer I get the warning message:
Windows protected your PC
Windows Defender SmartScreen prevented an
unrecognized app from starting. Running this app might put your PC at
risk.
If I right-click on the installer and choose Properties I note the following:
Our installer is signed.
How do I find the reason for the Windows Defender SmartScreen warning?
I have not managed to find any log file for Windows Defender nor found anything in the Event Viewer.
TL;DR
This warning is shown if your app doesn't have enough reputation with Microsoft SmartScreen yet. In order to gain reputation, you can either
submit your app for malware analysis to Microsoft,
buy an "Extended Validation" code signing certificate,
buy a standard code signing certificate, or
just wait for a long time.
Read on for the details about these different options.
Option 1: Submit your app for malware analysis to Microsoft
Microsoft allows software developers to submit a file for malware analysis. According to Microsoft, this will help developers to "validate detection of their products". If the review was successful, the Microsoft SmartScreen warnings will go away faster, or sometimes even instantly (it worked instantly for one of my own apps). You need to have a Microsoft account to submit your app for review.
However, note that if you release an updated version of your app, then you'll also have to request a new review again. To overcome this problem, you'll either have to use an "Extended Validation" or a standard code signing certificate (see below).
Option 2: Buy an "Extended Validation" code signing certificate
A guaranteed way to immediately and permanently get rid of the Microsoft SmartScreen warnings is to buy an "Extended Validation" (EV) code signing certificate from one of the Microsoft-approved certificate authorities (CA's), and to sign your app with that EV certificate.
Such an EV certificate will cost you somewhere between 250 and 700 USD per year, and will only be issued to registered businesses. If you're a single developer, you must be a sole proprietor and have an active business license. You can read more about the formal requirements for EV code signing certificates in the EV Code Signing Certificate Guidelines.
An EV certificate will typically be shipped to you by physical delivery on a hardware token.
Option 3: Buy a standard code signing certificate
You can also buy a cheaper "standard" (i.e. non-EV) code signing certificate, and sign your app with that certificate. This will also permanently, but not instantly, make the Microsoft SmartScreen warnings disappear. Standard code signing certificates will cost you between 100 and 500 USD per year, and can also be issued to private developers without an active business license. Some CA's also offer discounts for open source projects.
No instant solution
The problem with standard code signing certificates is that they do not instantly silence Microsoft SmartScreen. Instead, some time will be needed for your certificate to build reputation before the warning will go away. However, once your certificate has built enough reputation, all applications signed with that certificate will be permanently trusted by Microsoft SmartScreen and won't trigger the warning anymore.
How long will it take?
So, how long will it take until the Microsoft SmartScreen warning will disappear when using a standard code signing certificate? Unfortunately, this is difficult to answer, since Microsoft itself refuses to publish any details about this. According to inofficial numbers reported by various sources (see below), it usually takes between 2 and 8 weeks until the warning will permanently go away. It seems that the exact duration also depends on the reputation of the website from which your app is downloaded.
The inofficial numbers are:
18 days and about 430 app installs. Source: one of my own certificates (Dec 2022)
42 days and about 1.400 app installs. Source: one of my own certificates (Feb 2021)
16 days and about 2.000 app installs. Source: one of my own certificates (May 2020)
One month and more than 10.000 downloads. Source: here (Jan 2020)
Between a few weeks and a month. Source: here (Dec 2019)
About 2-3 weeks. Source: here (Dec 2019)
About 3.000 downloads. Source: here (Dec 2013)
The problem of certificate rollover
Certificate rollover occurs when your old certificate expires and you begin signing your code with a renewed certificate.
It's a good idea to buy your standard code signing certificate with the longest possible validity period because when you renew your certificate, the reputation will unfortunately not automatically carry over to the renewed certificate (not even if it's signed against the same private key as the old certificate).
However, you can mitigate the rollover problem by getting your renewed code signing certificate before your old certificate expires, and then using both the old (but not yet expired!) and the renewed certificate to sign your code, resulting in two signatures. The signature from your old certificate will continue to bypass SmartScreen and, at the same time, the new signature will help the new certificate to build up trust. So, the idea is that your new certificate becomes trusted before your old certificate expires.
If your old certificate should already have expired, then you can (and should!) still add the signature from your renewed certificate to an already released version of your app, in order to gain reputation for the renewed certificate.
To correctly dual-sign your app, first sign your code with the old certificate, and then sign it again with the renewed certificate, using the /as command line option of Microsoft's SignTool to append an additional signature to the first one (instead of replacing it).
Option 4: Just wait for a long time
If you don't take any measures at all, the Microsoft SmartScreen warning will also go away eventually. This might however take a ridiculous amount of time (months) and / or downloads (tens of thousands). Another big problem is that each time you'll release an updated version of your app, the waiting period will start all over again. So, this probably isn't the solution you're looking for.
After clicking on Properties of any installer(.exe) which block your application to install (Windows Defender SmartScreen prevented an unrecognized app ) for that issue i found one solution
Right click on installer(.exe)
Select properties option.
Click on checkbox to check Unblock at the bottom of Properties.
This solution work for Heroku CLI (heroku-x64) installer(.exe)
If you have a standard code signing certificate, some time will be needed for your application to build trust. Microsoft affirms that an Extended Validation (EV) Code Signing Certificate allows us to skip this period of trust-building. According to Microsoft, extended validation certificates will enable the developer to immediately establish a reputation with SmartScreen. Otherwise, the users will see a warning like "Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.", with the two buttons: "Run anyway" and "Don't run".
Another Microsoft resource states the following (quote): "Although not required, programs signed by an EV code signing certificate can immediately establish a reputation with SmartScreen reputation services even if no prior reputation exists for that file or publisher. EV code signing certificates also have a unique identifier which makes it easier to maintain reputation across certificate renewals."
My experience is as follows. Since 2005, we have been using regular (non-EV) code signing certificates to sign .MSI, .EXE and .DLL files with timestamps, and there has never been a problem with SmartScreen until 2018, when there was just one case when it took 3 days for a beta version of our application to build trust since we have released it to beta testers. It was in the middle of the certificate validity period. I don't know what SmartScreen might not like in that specific version of our application, but there have been no SmartScreen complaints since then. Therefore, if your certificate is a non-EV, it is a signed application (such as an .MSI file) that will build trust over time, not a certificate. For example, a certificate can be issued a few months ago and used to sign many files, but for each signed file you publish, it may take a few days for SmartScreen to stop complaining about the file after publishing, as was in our case in 2018.
We didn't submit our software to Microsoft malware analysis. Microsoft started to provide this service in 2017. It may be a viable alternative to an Extended Validation (EV) certificate.
In conclusion, to avoid the warning altogether, i.e., prevent it from happening even suddenly, you need an Extended Validation (EV) code signing certificate, and/or, you can submit your software to Microsoft malware analysis.
UPDATE: Another writeup here:
How to add publisher in Installshield 2018
(might be better).
I am not too well informed about this issue, but please see if this answer to another question tells you anything useful (and let us know so I can evolve a better answer here): How to pass the Windows Defender SmartScreen Protection? That question relates to BitRock - a non-MSI installer technology, but the overall issue seems to be the same.
Extract from one of the links pointed to in my answer above: "...a certificate just isn't enough anymore to gain trust... SmartScreen is reputation based, not unlike the way StackOverflow works... SmartScreen trusts installers that don't cause problems. Windows machines send telemetry back to Redmond about installed programs and how much trouble they cause. If you get enough thumbs-up then SmartScreen stops blocking your installer automatically. This takes time and lots of installs to get sufficient thumbs. There is no way to find out how far along you got."
Honestly this is all news to me at this point, so do get back to us with any information you dig up yourself.
The actual dialog text you have marked above definitely relates to the Zone.Identifier alternate data stream with a value of 3 that is added to any file that is downloaded from the Internet (see linked answer above for more details).
I was not able to mark this question as a duplicate of the previous one, since it doesn't have an accepted answer. Let's leave both question open for now? (one question is for MSI, one is for non-MSI).
I have prepared my MSI package using the Advanced Installer and then signed it using the SignTool:
signtool sign /debug /f "cert.pfx" /fd SHA256
/p "<pass>" /t http://timestamp.comodoca.com/authenticode "<file.msi>"
But, when other user is downloading the signed MSI via web-browser and to install it, the next message occurs:
My MSI has the next attributes:
digital signature, which was generated with paid/commercial
certificate (Comodo)
timestamp
there was used SHA-256 instead of SHA-1, because the last one is insecure in latest Windows
So, the main question is the next:
Why doesn't Windows recognize my signed MSI as well-known, if I have signed it with the commercial code-signing certificate?
PS
If you're interested in, which the version of Windows is used, then answer is the latest Windows 10.
About last one option from list, there is an interesting link, I shall quote some text from it:
Effective January 1, 2016, Windows (version 7 and higher) and Windows
Server will no longer trust new code that is signed with a SHA-1 code
signing certificate for Mark-of-the-Web related scenarios (e.g. files
containing a digital signature) and that has been time-stamped with a
value greater than January 1, 2016. This cut-off date applies to the
code-signing certificate itself.
SmartScreen Protection can show the above message when you try to run a newly released program or an application that has not yet established a reputation.
Reputation is established by SmartScreen® service intelligence algorithms based on how an application is used by Windows and Internet Explorer users.
For details, check the passing the smart screen on Win8 when install a signed application? thread that debates this subject.
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.
So... Microsoft has announced that SHA-1 code signing certificates are deprecated as of January 1st 2016. I've done a fair bit of reading, I've had our certificate reissued using SHA-256 instead of SHA-1, and I think I understand how to dual-sign binaries so the signatures will validate on older versions of Windows that don't support SHA-256.
Here's the problem: despite the fact that these rules are supposed to apply from January 1st 2016, it doesn't look like Windows has started enforcing them yet. I've signed a number of EXE files with our old SHA-1 certificate, timestamped them with dates after January 1st 2016, and Windows still seems to consider the signatures to be valid (at least on fully-updated installations of Windows 7 and Windows 10). I've checked this by right-clicking on a signed file in Explorer, selecting "Properties", then going to the Digital Signatures tab and double-clicking the certificate. It tells me "The digital signature is OK".
Am I misunderstanding something here? Or is there some kind of tool that I can use to check that a signed EXE (or MSI, or whatever) will be valid after Windows stops accepting SHA-1 certificates? I don't want to release products now and discover at some point in the future that the signatures are no longer valid. That would be embarrassing.
How would I sign a Visual C# executable?
SignTool.exe can't find a certificate.
How would I create a self signed key and certificate, and have signtool be able to see the certificate and use it?
OpenSSL and Visual Studio 2010 Express are installed. Running Windows 7 Ultimate x64.
Using SignTool.exe from Windows Driver Kit.
Using self-signed certificates for digitally signing your binaries pretty much goes against the concept of using digital certificates with programs. The basic idea is to prove the code was created by you (authenticity) and has not been modified since you released it (integrity). This must be done by using a signed certificate that is signed by a trusted Certificate Authority (CA).
With .Net, when a binary is digitally signed, it is automatically verified for integrity and authenticity during startup. While I have not personally tested this, using a self-signed certificate is probably going to cause you a great deal of problems.
If you want to digitally sign your programs, you need to invest in a code signing certificate from a CA. There are a number of companies out there that can provide this service (Verisign, Thawte), for a fee.
While the fee might seem a bit extreme in price, remember that you are not just purchasing a digital certificate but also 24/7 validation of that certificate. Any time someone starts your program it will ensure the program was written by you and that the program has not been changed since you released it.
Once you have a certificate, you can digitally sign your program by following the steps in How to: Sign Application and Deployment Manifests.
Update: If this program is strictly an internal application (limited to you or your business), you can created your own CA. Since you would be the only one running it, only you would need to validate it. The CA certificate would need to be installed as a Trusted Root Certificate on all the machines that would run the program (or if you have access to Windows Server, you could set up a real working CA).