I'm using the standard code signing certificate for signing our windows applications, but I'm still getting the "unrecognized app" message
(screenshot)
then i read that
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 to skip this period of trust building.
from here Codesign software still gives a warning on Windows 10
I want to know that how may downloads or how much time is required to build trust using standard code signing certificate?
The number of downloads or days until the SmartScreen may stop complaining about a software signed by a standard code signing certificate is not specified by Microsoft. We've only had this problem with SmartScreen once, and about halfway through the validity period of our standard code signing certificate, we released a new beta version of our program. The users posted about the issue on June 29, 2018, and the certificate was valid from June 16, 2016, to July 17, 2019. We did release betas often, but this is the only case where SmartScreen has complained. It has never complained before or since. The issue vanished within a day of June 29, 2018. The users downloaded that beta a few hundreds of times on that day until the issue vanished. Hope our experience can give you some references. However, the specific algorithm has not been disclosed by Microsoft, and it is still a mystery. While for us it resolved in one day with less than a thousand downloads, although we did release betas a few times a week, for the other people it took much more time and much higher number of downloads.
We didn't submit our software to Microsoft malware analysis. Microsoft started to provide this service in 2017.
We also have a few suggestions: all files that can be signed (.exe, .dll) should be signed inside the MSI. If you include binary custom actions into the MSI, these binaries should also be signed.
Related
I recently took on a task to update our filter driver from building with Visual Studio 2015 -> 2019. I also moved to the latest SDK + WDK 22000 (Which is the new Windows 11 one).
Everything seemed to work except that on Win 7 x64 (with secure boot) boxes the driver no longer loads.. It get's:
Load failed with error: 0x80070241
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damaged,
or that might be malicious software from an unknown source.
Our driver was/is attestation signed by Microsoft via the MS Hardware portal and so it's joint signed by both our company and Microsoft with a SHA-2 signature each. Windows 7 doesn't support SHA-2 certs out of the box however, it was previously working provided:
Windows6.1-KB3033929-x64
Was installed. Something seems to have changed though and Windows 7 x64 boxes can't load the new driver even with the latest updates. They load the 2015 built driver just fine even though the certificates on both look identical. The new driver loads just fine on Windows 10 machines.
Is anyone aware of any other changes which might make this combination fail to load?
I had a similar issue a few months ago, when we decided to switch our certificate provider. I'll share my knowledge to you, hope that going to help.
A while ago, Microsoft used cross-certificates to validate trusted certificate authorities (CA), so the only thing you needed to sign a driver is a proper certificate bought from a trusted CA. But recently validating process had changed and starting from Windows 10 20H2 you are forced to sign your driver through Microsoft Partner Center and all the cross-certificates was deprecated. However, you still need to use cross sign process for all your drivers prior to Windows 10, actually cross signed driver will work up to Windows 10 20H1 if to be correct.
Now back to the Visual Studio. To properly sign driver, you had to set up production certificate to field Properties -> Driver Signing -> General -> Production Certificate, that causes Visual Studio to use signtool utility to sign driver after the build done. As I presume, Visual Studio 2019 process do not use cross-certificate and looks something like:
signtool sign /v <trusted_certificate> /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a <sys_driver_filepath>
But Visual Studio 2013 actually must use cross-certificate and the command it uses is:
signtool sign /v /ac <microsoft_cross_certificate> /tr http://timestamp.digicert.com /a <sys_driver_filepath>
So what is cross-certificate is? It's a special trusted Microsoft certificate that tied to certified CA. List of all the cross-certificates available can be found here https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing#cross-certificate-list. To take the correct one you need to check your company certificate first. Take a look into root of certification path of your cert, open View Properties -> Details and find Issuer, that's your CA. Now you need to find exact match on cross-certificate list and download it. Note the thumbprint doesn't need to match (revealed in related issue). After all use a proper signtool command to sign your file.
P.S. If your certificate issuer not present on the list, that means your CA inappropriate and you need to get/buy another certificate.
So I built an Outlook VSTO Add-in, and in visual studio on the signing page selected a valid certificate which was bought from a Cert Authority. When I publish the add-in, it all works fine and the installer is trusted.
Here's where it gets weird - When I zipped and emailed it to a colleague they found that the application had an unknown publisher. So I downloaded it from the email I sent them on my pc (the one I built the app with) and sure enough the certificate seemed to be untrusted. Zipping and unzipping the files that I already had locally worked fine and the app was trusted, but the exact same file taken from my email is untrusted.
I'm completely baffled, don't even know how to start googling this issue - anyone got any ideas?
Figured out the answer for anyone else that runs into this problem.
The hash used by VS when creating a clickonce application is SHA1 (yes, even with VS2019), but SHA1 was depreciated by MS in 2017, meaning anything signed using it is not trusted by later versions of office. Thus you have to publish an unsigned clickonce application with Visual Studio, and then use the "Developer Command Prompt for VS" to sign the .exe with the cert using SHA265.
I would like to know what is the impact of dropping SHA1 code signing in favour of SHA256-only code signing as of October 2018. I am currently dual code signing my executables to ensure they will get validated on all versions of Windows starting from Windows 7 / Windows Server 2008 R2. There are many articles online showing code signing requirement matrices, but it's not so clear how many environments in practice won't validate SHA256-only signatures. From what I understood, SHA256 code signing support came in an update in Windows 7, but I don't know if this update is widely installed.
The reason I am asking is because I know it is just a matter of time before SHA256 is supported on all versions of Windows that are not in their end of life, and I am considering using AzureSignTool (https://github.com/vcsjones/AzureSignTool) which doesn't support SHA1 code signing.
it's not so clear how many environments in practice won't validate SHA256-only signatures.
Windows 7 / Windows Server 2008 R2 without KB3033929 will be affected.
Windows 8 or later is OK.
From what I understood, SHA256 code signing support came in an update in Windows 7, but I don't know if this update is widely installed.
I don't know too.
KB3033929 is included automatic Windows Update, but sometimes I get a question about this from Windows7 user (who don't install KB3033929).
I am looking to release an excel addin I built on my website, which the user's will download and install. It also has an auto update feature.
My problem is when the auto update feature runs it is not allowed save files to the user's machine because I dont have any code signing certificate I assume.
So, right now I am looking for a trial version of code signing certificate.
Does any one know about these things ?
Thanks in advance !!!
You can use SSL certificate. There are millions of SSL certificates available for free and trial version in the market. Google for SSL certificates.
I have a problem with a ClickOnce deployment of a Windows Forms application. When I built the new setup, and tried to export it overwriting as usual the previous setup, Visual Studio came up stating that my certificate is expired.
This behaviour is described in You receive an error message when you try to update a Visual Studio 2005 ClickOnce application after the certificate that was used to sign the installation expires and there is a workaround in RenewCert - Working Version. But these solutions are not applicable in my situation.
Another workaround involves taking back the system date of the deployment server to a date before the certificate expiry date (during the deployment operations) - but I see this as a very "last chance".
How can I fix this problem? Is there another workaround I can try?
I found a blog entry, ClickOnce and Expiring Code Signing Certificates by James Harte, that describes a method to have your application remove itself and launch the new ClickOnce install. It worked for me.
I ran into this problem almost two years ago. There is really no good workaround if RenewCert won't work for you. I even emailed the ClickOnce authority, Brian Noyes, and got confirmation that there were no good workarounds.
We ended up buying a 3 year cert and telling our users to uninstall. However, if I remember correctly, the users only got error messages when launching the app from the start menu. If they went to the web page, it installed the app and ran fine. Of course the client then had 2 versions of the app on their machines :). I can't remember what happened to the start menu shortcuts in that scenario.