I distribute a Windows desktop app which has all executable files digitally signed by a Verisign Class 3 Code Signing certificate. For the vast majority of users, this seems to work fine.
However a small number of users report the certificate is invalid. They say it comes up with the message "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider". This corresponds to error code CERT_E_UNTRUSTEDROOT (0x800B0109). This has also been reported on a fully-updated Windows 7 machine. So presumably my certificate is OK, but Windows sometimes doesn't trust VeriSign certificates.
Why does Windows sometimes not trust VeriSign? Is there anything I can add to my installer (also signed) which will tell Windows to trust the certificate?
There are frequent updates of the Root Certificates which Microsoft rolls out via Windows Update, but which are tagged as "optional update". Hence not all users may have them installed and may need to install them manually. This also holds for "fully updated" machines, as the automatic installation is often set to only install "important updates", which the Root Certificate updates are not.
Depending on the type of desktop application, you may have to follow certain rules when signing, too. For example applications interacting with the Windows Security Center require essentially the same signing method as drivers. That is, the certificate chain gets embedded along with the signature (/ac switch to signtool). You can get the MSCV-VSClass3.cer applicable to VeriSign certificates here.
The process is often called cross-signing, which seems to be a misnomer. While this is one step in getting your driver binary or catalog cross-signed, the vital step is that Microsoft signs the driver (or more usually the catalog file these days), which is the actual cross-signing.
Related
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
In 2014, I bought a class two code signing certificate from StartSSL which I used to digitally sign my binaries. This certificate has just expired and I actually am in the process of trying to get a new one. However, in an unrelated incident, I ran one of my signed setup programs in a VM and was somewhat ... annoyed ... when Windows brought up the "Unverified Publisher" variant of the UAC dialog.
When I view the digital signature properties I see this:
Of course the certificate has expired, but why is the file (that was signed within the validity period) suddenly unverified? I haven't seen this happen with other software, for example if I look at an old signed copy of Office 2003 setup, that doesn't complain about an invalid signature and that validaty period expired a decade ago.
Why is this? Frankly I'm now wondering what the the point of buying the certificate in the first place was and seriously considering cancelling the in-process replacement. Seems kind of pointless when they invalidate themselves. Or is this the different between class 2 and 3? (Class 3 is the version I'm trying to get hold of now)
This is apparently a by-design limitation on some code-signing certificates, as described in the first footnote to Microsoft's blog post, Everything you need to know about Authenticode Code Signing:
Not all publisher certificates are enabled to permit timestamping to provide indefinite lifetime. If the publisher’s signing certificate contains the lifetime signer OID (OID_KP_LIFETIME_SIGNING 1.3.6.1.4.1.311.10.3.13), the signature becomes invalid when the publisher’s signing certificate expires, even if the signature is timestamped. This is to free a Certificate Authority from the burden of maintaining Revocation lists (CRL, OCSP) in perpetuity.
You may wish to check whether the replacement certificate will have the same limitation, and perhaps consider an alternative vendor.
I have successfully installed a self-signed certificate to Windows 7.
The procedure was to install it first to the Trusted Root Certification Authorities (Local Computer)
and then to install it to the Trusted People (Local Computer).
(Without installing it to Trusted People Internet Explorer 11 was still issuing a warning that it cannot be verified up to a trusted certification authority).
I tried repeating the same procedure on a Windows XP machine (yes, they still exist even after their support ended:) without luck.
I still get a warning the certificate cannot be verified up to the trusted certification authority.
When I look at the Certificates Internet Explorer 8 shows me. The certificate itself is missing (although when looking in certmgr.msc, I can see the certificate).
For some reason Internet Explorer chooses to ignore this certificate.
Any ideas what's going on?
Looking at certificate in the Windows Certificate Manager (certmgr.msc). Windows says it "does not have enough information to verify this certificate".
When looking at the certificate path, the only certificate that is shown is the certificate itself (with a yellow exclamation mark), and the Certificate status indicates:
"The issuer of this certificate could not be found".
I looked carefully at the details of the faulty certificate to find why is it different from other certificates.
The issuer's name was clearly correct so this wasn't the problem.
The field that drew my attention was "Authority Information Access"
The reason was is that it contained extra data with a "URL=http:...name_of_domain.cer".
This link is to the intranet the organization uses. I've downloaded the certificate on the intranet and installed it on the client.
The certificate became valid, and now it shows two certificates in the "Certification Path"
Conclusions.. It turns out Windows XP is dumb for two reasons:
Installing a certificate that has a chain to the Trusted Root Certificates is not enough for Windows XP. it tries to validate the Root Certificates up to their top of the chain (This doesn't make a lot of sense, since it should be a Root Certificate, and since Windows 7 doesn't follow this behave and accepts the certificate as valid).
Since both the certificates held the same Common Name, Windows XP fails to show that the original certificate does have a chain. and made it alot more difficult to track down the issue.
Hope this helps anyone who will encounter this in the future. (or not since Windows XP supported ended, as we all know:) )
For my Windows-based application, I would like to use ClickOnce as the deployment technology. My application will be distributed via the Internet.
In the article ClickOnce and Authenticode, I read that:
For ClickOnce applications, you must have an Authenticode certificate
that is valid for code signing. You can obtain a certificate for code
signing in one of three ways:
Purchase one from a certificate vendor.
Receive one from a group in your organization responsible for creating
digital certificates.
Generate your own certificate with MakeCert.exe, which is included
with the Windows Software Development Kit (SDK).
In my case, number 2 is not applicable.
As I read a few rows later:
By default, ClickOnce applications signed with self-certs and deployed
over the Internet cannot utilize Trusted Application Deployment.
(Emphasis mine.)
I cannot understand the meaning of this by default. Is the option #3 possible or not in my case?
And then, to understand all the possibilities, what does the #1 imply ? ("Purchase one from a certificate vendor") What kind of certificate should I buy? Which certificate authority can be recommended? Depending on what I should choose? How much does a certificate cost?
It must be a "Microsoft Authenticode Certificate". It allows us to sign all kinds of Windows executables and code, including .exe, .cab, .dll, .ocx, and .xpi files.
It is not mandatory to sign an application, but if we do it our users won’t see a warning message stating that the author of the software is unknown.
Microsoft Authenticode Certificates need to be issued by a trusted certificate authority. Unfortunately, the prices are quite expensive. More information and some examples
are on page Microsoft Authenticode Certificates.
UPDATE I purchased the certificate through KSoftware, which is a Comodo retailer. The price is quite good compared to alternatives: $95/year. The process is faster than I expected: I applied in the morning and in the evening my certificate was already available. (For those interested, I followed this step-by-step guide.)
See my answer to Stack Overflow question How to sign a ClickOnce application.
I would definitely suggest getting a proper code-signing certificate - your application install screen will look much nicer in this case.
StartCom CA is closed since Jan. 1st, 2018 I got my code-signing certificate from http://startssl.com - and it was $100 or so in total (and you get wild-card domain certificate for your website as well as a bonus).
It's much cheaper than going with VeriSign or TrustWave.
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).