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.
Related
Windows 10 started reporting my application as "Unknown publisher" when I try to run it after a download.
However, after accepting the installation, it recognizes my company as a publisher:
The application is signed with a certificate from Comodo:
It is a very unpleasant situation. How to fix the problem?
Starting with January 1st, 2016 Microsoft is implementing a mandatory update of the Digital Signature system from SHA-1 to SHA-2 in order to deal with the decreasing security of the SHA-1 digital signatures.
All applications signed with SHA-1 certificates will still be accepted until January 1st, 2017. The UAC prompt will still show the correct vendor information but the browser, i.e. Internet Explorer, will warn the users about an invalid signature. Also, the Windows SmartScreen will not recognize the SHA-1 signature and try to prevent the users from running it.
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.
I made a driver, and now I need to sign it. It runs in kernel mode.
From what I've read in Microsoft's Kernel Mode Code Signing Walkthrough, I have to buy a software publisher certificate from a commercial CA. In that document, they say to look at the end, and follow this link for a list of CAs from which I can buy that certificate. I find the link very confusing somehow because I can't figure out exactly what certificate I need to buy. I need to sign the driver so that it will install on 64-bit Windows systems. A direct link would be very welcome (I would like to buy it from GlobalSign).
Is it the Microsoft Authenticode from here?
I asked a similar question in Microsoft Drivers Developers Forum some time ago. This is their answer:
You need to have your company get a code signing certificate from either GlobalSign or VeriSign (the others listed in that link are no longer offered). GlobalSign is cheaper, but Verisign has the advantage of providing access to WHQL if that is of interest to your firm. These are not cheap, the Verisign certificate costs $499 per year. Once you have
the cert you can use it instead of the test cert to sign the driver.
Your link contains this information in Supported Platforms: Digitally sign Windows ActiveX controls via Authenticode (32 bit and 64 bit .exe, .ocx, .dll or other) and kernel software for Windows. Windows 7 compatible.
It looks like you are in the right place.
Just to be precise: I have not used the code certification yet, I just learned it. I recommend you to verify this answer in osronline or Microsoft Drivers Developers Forum.
Check out https://www.startssl.com/?app=40 - StartSSL offers such certificates for US$ 199.00
The cross-signed CA certificate is at https://www.startssl.com/certs/ named microsoft.kernel.mode.pem or microsoft.kernel.mode.crt
You can buy a signature from Digicert.
Digicert will issue a cross signing certificate in a zip file. Unzip it
DigiCert High Assurance EV Root CA.crt
Double click it and add it to your IE personal store
Using IE, export the cert, with password to a .pfx file
The command to sign the driver is
signtool sign /t http://timestamp.digicert.com /f "path to .pfx file" /p PASSWORD_OF_PFX "path to driver .cat file"
You can use this same command to sign .exe files
signtool sign /t http://timestamp.digicert.com /f "path to .pfx file" /p PASSWORD_OF_PFX "path to driver .exe file"
Ensure this machine has internet access otherwise the signing process will fail.
I have an EXE file that I should like to sign so that Windows will not warn the end user about an application from an "unknown publisher". I am not a Windows developer. The application in question is a screensaver generated from an application that generates screensaver applications. As such I have no influence on how the file is generated.
I've already found out that I will need a code signing certificate from a CA like Verisign or instantssl.com. What I don't understand is what I need to do (if at all possible) to sign my EXE file. What is a simple explanation?
Mel Green's answer took me further, but signtool wants me to specify what certificate to use in any case. Can I get a free code signing certificate somehow to test if this will work for me at all?
Also please specify which certificate kind is the correct one. Most sites only mention "code signing" and talk about signing applications that are actually compiled by the user. This is not the case for me.
How to sign your app
Use Microsoft's SignTool to sign your app.
You download it as part of the Windows SDK. Note that it's also possible to install SignTool without installing the entire SDK. Once installed you can use SignTool from the command line like so:
signtool sign /a /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 MyFile.exe
This will sign MyFile.exe. Explanation of the used command line options:
/a will automatically use the certificate that is valid for the longest time. If you have no certificate, SignTool will display an error.
/fd SHA256 will use the SHA-256 digest algorithm for the file signature. Using SHA256 is recommended and considered to be more secure than the default SHA1 digest algorithm.
/tr http://timestamp.digicert.com adds a timestamp to your signed apps. This is extremely important because this will allow the signature to remain valid even after the certificate itself has already expired. The argument for the /tr option is a timestamp URL. You can use any of the timestamp URL's from this list of free RFC 3161 timestamp servers.
/td SHA256 will use the SHA-256 digest algorithm for the timestamp signature. As before, using SHA256 is recommended and considered to be more secure.
How and when to use self-signed certificates
If you'd like to get a hold of a certificate that you can use to test your process of signing the executable, you can use MakeCert to create a self-signed certificate.
Once you've created your own certificate and have used it to sign your executable, you'll need to manually add it as a Trusted Root CA for your machine in order for UAC to accept your self-signed certificate as a trusted source. Note that you can only do this on your own development machines. You usually can not do this on your user's computers, since most users will not accept to install a new Root CA for good reasons.
How to get rid of the "unrecognized app" warning
Even if your app is signed, you might still see the following warning message when trying to run the app:
Microsoft Defender SmartScreen prevented an unrecognized app from
starting. Running this app might put your PC at risk.
How to avoid this warning is a somewhat complex topic. Please see this answer to get the whole picture about these Microsoft SmartScreen warnings and what you can do and should know about it.
I had the same scenario in my job and here are our findings
The first thing you have to do is get the certificate and install it on your computer, you can either buy one from a Certificate Authority or generate one using makecert.
Here are the pros and cons of the 2 options
Buy a certificate
Pros
Using a certificate issued by a CA(Certificate Authority) will
ensure that Windows will not warn the end user about an application
from an "unknown publisher" on any Computer using the certificate
from the CA (OS normally comes with the root certificates from manny
CA's)
Cons:
There is a cost involved on getting a certificate from a CA
For prices, see https://cheapsslsecurity.com/sslproducts/codesigningcertificate.html and https://www.digicert.com/code-signing/
Generate a certificate using Makecert
Pros:
The steps are easy and you can share the certificate with the end users
Cons:
End users will have to manually install the certificate on their machines and depending on your clients that might not be an option
Certificates generated with makecert are normally used for development and testing, not production
Sign the executable file
There are two ways of signing the file you want:
Using a certificate installed on the computer
signtool.exe sign /a /s MY /sha1 sha1_thumbprint_value /t http://timestamp.verisign.com/scripts/timstamp.dll /v "C:\filename.dll"
In this example we are using a certificate stored on the Personal folder with a SHA1 thumbprint (This thumbprint comes from the certificate) to sign the file located at C:\filename.dll
Using a certificate file
signtool sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /f "c:\path\to\mycert.pfx" /p pfxpassword "c:\path\to\file.exe"
In this example we are using the certificate c:\path\to\mycert.pfx with the password pfxpassword to sign the file c:\path\to\file.exe
Test Your Signature
Method 1: Using signtool
Go to: Start > Run
Type CMD > click OK
At the command prompt, enter the directory where signtool exists
Run the following:
signtool.exe verify /pa /v "C:\filename.dll"
Method 2: Using Windows
Right-click the signed file
Select Properties
Select the Digital Signatures tab. The signature will be displayed in the Signature list section.
I hope this could help you
Sources:
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537361(v=vs.85)
https://www.digicert.com/kb/code-signing/signcode-signtool-command-line.htm
https://learn.microsoft.com/en-us/windows/win32/seccrypto/makecert
https://cheapsslweb.com/comodo-code-signing
You can get a code-signing certificate from Certum if you're doing open source development. I've been using their certificate for over a year, and it does get rid of the unknown publisher message from Windows. Price history:
2005 - €14.00
2019 - €25.00
2022 - €69.00
As far as signing code I use signtool.exe from a script like this:
signtool.exe sign /t http://timestamp.verisign.com/scripts/timstamp.dll /f "MyCert.pfx" /p MyPassword /d SignedFile.exe SignedFile.exe
Another option, if you need to sign the executable on a Linux box is to use signcode from the Mono project tools. It is supported on Ubuntu.
The ASP's magazine ASPects has a detailed description on how to sign code (You have to be a member to read the article). You can download it through http://www.asp-shareware.org/
Here's link to a description how you can make your own test certificate.
This might also be interesting.
This is not a direct answer to the question, but it is closely related (and useful I hope) since sooner or later any individual programmer will have put his hand into the wallet.
So, prices for EV (Extended Validation) Code Signing Certificates, sorted by price:
AboutSSL
$240/Year (clickbait price)
$287/Year (real price, after coupon)
KSoftware.net
1 Year $350 + ($50 hidden fee!)
2 Year $600
3 Year $750
OV: $84 per year (for 3 years)
I purchased from them an EV. Some years later I purchased an OV. The eToken was sent on a USB stick. No reader needed. They are only intermediary. In the end, you actually purchase from Comodo (Sectigo).
Sectigo is veeeeerrry slow.
The second time, the verification took two full months. The phone verification failed multiple times. Everything was cumbersome. The tech support didn't have a clue about what is going on, probably just a guy in Pakistan reading through some script.
Sklep.certum.pl
1 Year 379 euro
(seems to be for Poland users only)
LeaderSsl.de
1 Year 364 euro or 307 euro (+19%VAT)
(OV 69+VAT)
Sectigo.com
1 Year $499 USD
3 Year $897 USD
GlobalSign.com
1 Year $410 total
2 Years $760 total
3 Years $950 total
Digicert.com
1 Year: $600 (it was $104)
3 Year: ?
symantec.com
1 Year: $700
3 Years: ridiculous expensive
More prices here:
cheapsslsecurity.com CodeSigning EV
cheapsslsecurity.com SSL only!
EV vs OV
With EV, nine additional steps are required including verifying a businesses’ public phone number, length of time in business, registration number and jurisdiction, as well as a domain fraud check, contact blacklist check and a telephone call to authenticate the employment status of the requestor.
Some recommend submitting a program signed with OV to Microsoft to be checked with their antivirus.
IF YOU FIND CHEAPER PRICES, let me know, and I will update the list!
How to use the certificate?
To sign the exe file, I used MS signtool.exe. For this you will need to download the bloated MS Windows SDK which has a whooping 1GB. FORTUNATELY, you don't have to install it. Just open the ISO and extract "Windows SDK Signing Tools-x86_en-us.msi". It has a merely 400 KB.
Then I built this tiny script file:
prompt $
echo off
cls
copy "my.exe" "my.bak.exe"
"c:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64\signtool.exe" sign /fd SHA256 /f MyCertificate.pfx /p MyPassword My.exe
pause
__
What happened after signing my EXE file?
So, after investing some money, I finally signed my EXE file. What happened after that? Nothing... On Win10 I still see the same "untrusted" window with the "Don't run" button. The "Continue" button is still invisible. My program has about 400 downloads per day. Let's wait and see how many downloads are necessary.
Reference https://steward-fu.github.io/website/driver/wdm/self_sign.htm
Note: signtool.exe from Microsoft SDK
1.First time (to make private cert)
Makecert -r -pe -ss YourName YourName.cer
certmgr.exe -add YourName.cer -s -r localMachine root
2.After (to add your sign to your app)
signtool sign /s YourName YourApp.exe
And yet another option, if you're developing on Windows 10 but don't have Microsoft's signtool.exe installed, you can use Bash on Ubuntu on Windows to sign your app. Here is a run down:
https://blog.synapp.nz/2017/06/16/code-signing-a-windows-application-on-linux-on-windows/
Use following link to sign .exe (setup/ installer)file (sign exe/setup file without using Microsoft setup signtool)
https://ebourg.github.io/jsign/#files
sample command java -jar jsign-2.0.jar --keystore keystore.jks" --alias alias --storepass password MyInstaller.exe
Worked for me :)