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:) )
Related
I have coded an NWjs Windows application (Chromium application) and using Inno Setup, I have signed it using a self-signed certificate. However, I get the "Windows protected your PC" message when trying to install it from the web. I wonder now if signing my application with this self-signed certificate is useless because I get the same result when I don't sign the application and package it as it is.
When I click "more info" it states that the publisher is unknown in both cases when I sign the application with a self-signed certificate and without a self-signed certificate.
I wonder if after sometimes, the data (like the CN of the subject) of the certificate helps to get some reputation when the application is distributed on the internet. I wonder if a self signed certificate help to get rid of the "Windows protected your PC" message after sometimes.
Self-signed certificates are useful only, if can make them trusted on the target machine, by deploying them to Windows certificate store, before installation.
If you want your application to be installed on machines that you do not control, self-signed certificates are useless.
I wonder if a self signed certificate help to get rid of the "Windows protected your PC" message after sometimes.
No. Since everyone can generate a certificate himself, Windows cannot trust all of them and therefore cannot remove the message.
However, it can still be a good idea to sign an executable with your own certificate, if you publish the public key and provide it for people to check whether or not the executable was indeed provided by you. It will be useful for people with some IT or security knowledge.
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.
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).
ClickOnce is suppose to use a signing cert for distribution. If I was developing a major app, I could understand purchasing a cert. However, my app is for a small sized company and I cannot justify the expensive.
My question is, when my app first installs, how might I install my self signed Root CA into Trusted Root Certificates automatically so there are no issues with my self signed program?
My current self signed CA Root and program cert were setup between Exchange 2010/IIS 7.0 and OpenSSL. The clients will be remote so I do not want to use Microsoft's Certificate Authority. You can see how I developed the certs at http://www.tekcrack.com/creating-your-own-self-signed-sans-certificate-for-exchange-2010-and-iis-70-1of3.html
Has anyone encountered the same problem? What route did you take to work around it...for free?
I don't know if that certificate will work for ClickOnce deployment. What you need is a code-signing certificate. I think you can buy one from GoDaddy for less than a hundred bucks, which is pretty inexpensive for giving your customers that nice warm feeling of having a trusted publisher.
If your customer has a domain administrator and any kind of central IT group, they can create a certificate for you that will be trusted.
You can't install a certificate programmatically on the user's computer. A ClickOnce application will not have that level of privilege. You have to have the customers install the certificate. Plus, it would be a huge security gap if people could install certificates without the user's knowledge.
And my last words of wisdom -- be sure your certificate is password-protected, and nobody can get their hands on it. If they do, and the certificate is installed in the store on the users's computer, they will be able to install applications on the user's computer in your name.
Having said all of that, I think this article will be helpful to you:
http://msdn.microsoft.com/en-us/library/ms996418.aspx#clickoncetrustpub_topic1
We have just received some new computers for use in the office (Dell Vostro). They seem to work fine in the main. When we use IE8 to go to some web pages such as yahoo mail it tells us:
“There is a problem with this websites security certificate”
If we have a look at the details it says:
“This certificate cannot be verified up to a trusted certification authority”
This however works correctly in Firefox. I don't understand why I should get such an error message, should this not just work?
The PC has Windows & (64 bit) and Norton Internet Security installed.
Don't forget that every browser comes with it's own list of trusted root server certificates.
Eg. from microsoft:
The Internet Explorer Certificate Manager enables you to install and remove trusted certificates for clients and CAs. Many CAs have their root certificates already installed in Internet Explorer. You can select any of these installed certificates as trusted CAs for client authentication, secure e-mail, or other certificate purposes, such as code signing and time stamping. If a CA does not have its root certificate in Internet Explorer, you can import it. Each CA's Web site contains instructions that describe how to obtain the root certificate.
Or from mozilla:
View Certificates: Click this button to view stored certificates, import new certificates, and back up or delete old certificates in Firefox.
So if IE and FF come with different lists of trusted Certificate Authorities, then some sites's certificates will be verifiable with one browser, but not the other. I would imagine that a high-profile organisation like Yahoo would use a highly profile CA that would be installed in both browsers.
I had the same problem with every website using windows 7 professional 64-bit and i realized that my clock was wrong so i changed it to the correct time and date and VIOLA! it worked.