We are using SignTool.exe with a ComodoSSL certificate to sign our *.msi-packages on Windows. While Windows 7 only displays the company name (say "My Company Inc.") when executing an MSI which has a "mark of the web", Windows 10 SmartScreen shows "DE, 12345, My State, My City, Our Street 123, My Company Inc., My Company Inc.", which is not really readable.
Our certificate contains this information:
In Windows in certificate details, the field "applicant" [note: this is my own translation from german, maybe the field name is slightly different] shows the following: CN=My Company Inc., O=My Company Inc., ...)
It worked with the same certificate on Windows 10 before setting up the new build environment. I've already tried the Windows 7 SDK and the Windows 10 SDK, same result.
Does anyone know, if I can force Win10 SmartScreen to display only the certificates Common Name?
I'm having the exact same issue with my Comodo certificate. In my case it's an Adobe AIR app which I'm building in Flash Builder and then signing with signtool. (Flash Builder seemingly only uses the certificate to sign the internal AIR package, not the installer EXE.)
It worked perfectly about two weeks ago, but it seems the problem began after a recent Windows update, so I assume somehow it's related to that. I've had a support ticket in with Comodo for the past few days, but they're not responding in spite of my repeated requests via their chat support. I think they're stumped as well.
UPDATE: It definitely seems that a Windows update is the source of the issue. Over the weekend one of our test computers auto-updated. Last week this computer was showing only our company name as the publisher on SmartScreen. After the update, it shows the same long jumbled-up address string.
Four updates were installed: KB3176935, KB3176936, KB3176937, and KB3194496. I tried uninstalling them one by one to see if it would fix the issue. Nothing changed with *35, *37, or *96. KB3176936 is a service stack update and cannot be uninstalled, so I have to assume it is the culprit. However, since I can't uninstall, check, reinstall, and check again, there is no way to verify that.
Comodo Support was no help at all. I sent them a screenshot of the issue, and their reply was: "We don't see anything wrong. Maybe you should send us another screenshot?" :/
At any rate, yes, I would be very interested in hearing anything you get back from Microsoft Support. I might try putting in a ticket with them myself as well.
Related
We have Windows application (MSI install package), downloadable from our site. The problem is, that browsers and 3rd party antiviruses prevent some users from download an APP. Is there a way to make our MSI package more trustable for browsers and antivirus? Maybe it can be checked and uploaded in some other resource, and downloadable for users from here?
P.S. We use code signing certificate, and Windows store is not a variant for us now.
Reputable anti-virus vendors have a way you can send your installation packages to be "whitelisted". Browsers have their own heuristics and using an EV certificate (more expensive) is supposed to help. Edge also supposedly respects the Defender whitelist.
Ultimately, the more downloads you get, the better your URL's reputation, the better you pass the heuristics.
We've been building and releasing the same application for almost 20 years and AV false positives can still create problems. This is how we do it today:
After each release, we scan our new setup on https://www.virustotal.com/gui/home/upload and if we notice any AV vendors flagging it we reach out to each of them and submit a request for false positive removal. They all have some form or email address where you can contact them.
They usually process these requests in a few days, so no real big problem for our users and doesn't take a lot of time.
Now, with SmartScreen, there is another story. Even if our package was digitally signed for over a decade, 2 years ago when we renewed our certificate Windows flagged our installer for about 2-3 months.
This was an installer with hundreds of thousands if not millions of users in the last decade. In the end, its reputation system got back to normal and stopped flagging it but it was really annoying for our customers.
The solution to this is to buy an EV certificate (confirmed by some of our customers) and then you will get an instant reputation with SmartScreen. This Spring our normal certificate expires and we will go the EV route too.
You can read more about digital signing and EV certs in the following articles:
Why EV Code Signing? EV Code Signing vs. Regular Code Signing
How to avoid the "Windows Defender SmartScreen prevented an unrecognized app from starting" warning
I have a client site running our Windows desktop software on a number of computers with 64 bit Office 365.
On most of their computers, our software is able to send email via Outlook.
However, two of their computers were upgraded to 365 last year (by their IT technician, not us), and both fail when they attempt to send email from our software.
Outlook works fine on its own, and so does our software - on both of these computers. But these two both can't send email from our software. (The other computers, which send email fine, are running exactly the same version of our software.)
When sending email, our software first checks for the existence of "Outlook.Application" or "Outlook.Application.*" keys in the Windows Registry to determine whether Outlook is installed. If not found, our program logic assumes that Outlook isn't installed, and attempts to use MAPI instead to send mail through another email client like Thunderbird (or through Outlook using MAPI). However, these computers both then crashed, because MAPI doesn't work on 64bit computers.
When I investigated these two problem computers, I found that they both had no "Outlook.Application" or "Outlook.Application.16" keys anywhere in their Windows Registry. I have never encountered this before. How and why would Office 365 install without creating these Registry entries? (I had just installed Office 365 on two computers here in my office, and they both had these keys and worked perfectly. And we have never encountered this before, at any of our other user sites.)
I discussed this with their IT technician. He did a complete uninstall of Office 365, and installed them from scratch, using the "on-line" install (that I had used on my computers - I sent him the URL to be sure). However, after this they were still unable to send email. When I investigated, I found that the Registry keys were still missing.
Their IT technician then asked me to export all the "Outlook.Application" and "Outlook.Application.16" keys in "Computer\HKEY_CLASSES_ROOT" and send them to him. He imported these on both those computers, but it did not fix the problem.
However, because the keys now existed, our software then attempted to send email directly through Outlook, using OLE. However it crashed on the line where it tried to create an Outlook Application Object:
loApp = CreateObject("Outlook.Application.16")
I built a special version with some extra test code in it. After failing to run the above line, it tried to run a line:
loApp = CreateObject("Outlook.Application")
This also failed - presumably because some Outlook application components have not been installed.
I did some fairly extensive Google searches for posts that might identify a solution, but found nothing that seemed to fit. A couple of posts suggested running an Office "Repair" from the installation tool.
I mentioned this to their technician, and he did this. Interestingly, when I then checked (using RegEdit), it had created a lot more "Outlook.Application" and "Outlook.Application.16" Registry keys. But our software still fails on both the "CreateObject" lines in that test version, and single "CreateObject" line in the normal version.
Both their technician and I are completely mystified (and now out of our depth in the Microsoft black arts of Office 365 installation and Windows).
Has anyone encountered this scenario before, and / or can suggest where we might go from here?
OK, the original post was getting a bit long, and I didn't want to clutter it with too much information. So here is some further info:
In answer to Eugene's questions:
Using RegEdit, I searched the entire Registry - for one of the
computers that didn't work, and one that did (plus my own here,
which also worked fine).
Their technician installed the latest 64 bit 365. If I understand
correctly, the initial install was done from an ISO file. When that
didn't work, he tried again using the "on line" install (which I had
successfully used here). He used the "on line" install again for the "repair". I don't have current build numbers, but could obtain these later in the week if relevant. But they should be up-to-date.
No we can't reproduce the problem ourselves in-house, and have never
seen it before at any other client site.
The site is running the same antivirus software on all computers (those
that work, and those that don't). So I suspect that this won't be
the cause.
Registry keys that match perfectly on those two computers are:
Computer\HKEY_CLASSES_ROOT\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_CLASSES_ROOT\Outlook.Application
Computer\HKEY_CLASSES_ROOT\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Backup\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocServer32
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\RegisteredApplications
Something that may be significant:
The Windows Registry on the computer that does not work has four extra keys (that are not in the computer that does work):
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
That computer (which doesn't work) also has a folder C:\ProgramData\Packages\Microsoft.Office.Desktop.Outlook_8wekyb3d8bbwe\ with 3 subfolders in it (with system generated names):
The first (created in 2019) has a subfolder "\SystemAppData" which is
empty.
The other two (both with same date/time in early 2020) are completely
empty (i.e. have no SystemAppData subfolder)
I wonder whether these keys may somehow be causing mischief. Early next week the technician and I plan to back up these keys, and then delete them.
Does anyone know what these keys are about?
(I found a blog that may be relevant: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/ But then again, it may not be.)
Keep in mind that older version of Windows Store Outlook ran in a sandbox and was not externally accessible. Uninstall it and reinstall again from the store - you will get a regular C2R version.
Eureka!!! Deleting those extra legacy Registry keys did the trick.
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Our software immediately was able to create Outlook Application objects, and send email via Outlook.
It seems that these extra keys dated back to an earlier attempted install by the client (before their current technician became involved). There were about 20 or so other 'Outlook*' keys in that part of the Registry with '8wekyb3d8bbwe' in their name. I subsequently deleted these too - on the the assumption that they were all legacy garbage. (As a rule, it is pretty dangerous to delete things you don't understand - but so far, so good. Although I am too chicken to delete a host of others in that location for Access, Excel, PowerPoint, Word with with '8wekyb3d8bbwe' in their name too.)
I had the same problem; it came from a brand-new computer!
What worked for me was the early binding. Select: Tools > Reference > Microsoft Outlook 16 object library.
Dim objOL As Outlook.Application
Set objOL = New Outlook.Application
Set objOL = Nothing
At the end, setting objOL to Nothing is crucial, otherwise the instance stays open, and it causes problems with Outlook.
Reference.
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).
So I had a certificate from Comodo and bought via KSoftware that I use to sign my software so it does not generate a warning when users download it, this has been working fine but the 2 year certificate expired last month. I purchased a new certificate last week and applied to a new version of my application but now when I download it warns me unknown publisher, and wierdly when I click on more info it shows my full address instead of just my company name JThink.
I have looked at my old and new certificate in browser and noticed I had Jthink ltd in old certificate and JThink in new one, would this cause an issue ?
Update
Comodo tell me there is a period of time before Microsoft start accepting new certificates and it would still be a problem even if the company information was identical because the certicate no is different.
Is this true, and what length of timescale are we talking about here ?
You need to just wait some time. Windows collects different data for your new certificate (total downloads count, etc.) and in some near future (depends on downloads rate) it will mark it as white listed (if it's all OK). And all your downloads signed using this new certificate will not be blocked anymore.
The same mechanism applies (as I think) on downloads without certificates at all. Windows collects the file reputation and after some critical amount of "good-experience" downloads it marks the file as OK. The same logic applies to certificates. Thus you do not need to wait anymore if your certificate has a "good reputation".
You need to use Extended Validation Code signing certificate which provides more trusted security certificate for your Windows binary. Regular code signing certificates are not validated by Windows smart screen protection.
I had the similar issue when Windows 10 was released with Windows smart screen protection with more advanced security features.
https://www.digicert.com/code-signing/ev-code-signing.htm
I use slartoolkit.dll file for windows augmented reality. It working well in my mobile(Nokia Lumia 510) and emulator. then i will send that xap file only to windows phone Store Certification center but test Result is Fail. I don't know what mistake i did.
please any one give me a suggestion
Without knowing the exact error the certification gave you it's hard to say why it failed. I have 25+ apps published and its RARE that I get an app to pass cert on the first time. There is always something small that you miss. A back button crash, forgetting to shut off sound, color settings wrong. There's endless possibilities.
That said, you need to check that the dll is certified for the windows phone. I know that I recently tried to implement a Physics Helper dll just to find out that unsigned dlls are no longer authorized on the windows phone. I believe that it died out with the release of 7.5 but I could be wrong.
Hopefully this gives you some insight and answers your question. Your best bet though is to post the certification failure PDF they sent you. Look in the email it should be attached.
Until there here is some reading material. Microsoft Certification Requirements
Also try using the built in certification tests within Visual Studio Market Test Kit