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.
Related
I've created a UWP app using Xamarin Forms in Visual Studio. It is ready for release, and I do not intend publishing it to the Windows Store. Under the "Packaging" tab of Package.appxmanifest, I created a test certificate via
Configure Certificate... >> Create test certificate...
and then created the app package. I can install the application on my own device (that was used to create and publish the app) using the .appxbundle file in the package, but any other device will not install the app, saying that "Either you need a new certificate installed for this app package, or you need a new app package with trusted certificates. Your system administrator or the app developer can help. A certificate chain processed, but terminated in a root certificate which isn't trusted (0x800B0109)"
On the devices giving this error, I have installed the certificate using the Certificate Import Wizard to both the local machine's "Trusted Publishers" and "Trusted Root Certification Authorities" stores, as well as whatever stores were chosen using the automatic option, then restarted the device. When I go into Digital Signature Details under the .appxbundle file's properties, it says that "The difital signature is OK", but still gives me the same error when I try to install the app.
If there is an issue with my certificate, which says it expires on 1/7/2019, how can I create a certificate that will work? Otherwise, have I incorrectly installed the certificate on the device? I have double and triple checked and the device is set to Developer Mode. It is also on the same version of Windows 10 that my device is on.
I have also tried right clicking the .ps1 file and running with powershell, which gives me the same error. I have been following these instructions to this point: https://learn.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps#before-packaging-your-app
I've discovered the issue on my own. I had mistakenly installed the certificate to "Third-Party Certification Authorities" instead of "Trusted Root Certification Authorities". Once I installed the certificate to the proper stores the app was able to install.
For UWP apps, the certificate must be placed in the Trusted People store.
In my case I have installed certificate for current user instead of local machine. I installed for local machine and it works .
Also installed for for all 3 types of as shown below
Personal
Trusted root ....
Trusted Publisher
and things start working for me after 2 hours of effort.
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:) )
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.
I'm working to upgrade our source control from hg 1.6.0 to 1.8.2 and I'm looking to set up and use SSL certs. This is on a Windows Server 2008 Enterprise system running IIS 6.0, not my server so I need to use those versions of software right now. All my users are running Windows too.
To ease installation/configuration for my users I'd prefer to modify the Windows Cert Store instead of the cacert.pem file. Does Mercurial have access to the Windows Certificate Store? It doesn't seem to. I am using internally created certificates and I can get things to work without SSL warnings by adding my root cert to the cacert.pem file in Mercurial but I can't seem to get it to work by adding the certs to the Windows Cert Store. Am I missing something?
Thanks,
Scott
No, Mercurial does not access the Windows certificate store.
It includes in its distribution a cacert.pm (as you know, even though before 1.7.3, the story was a bit different)
The article "X.509 certificates and Mercurial" has more information.
A principal thing to remember here is that Mercurial will not work as a complete server out of the box, requesting authentication information, in the form of basic, digest, or certificates, at all.
This means that in order to use X.509 certificates with Mercurial, one needs to place a web server that knows of these authentication mechanisms in front of it.
This article includes makecert.exe, which actually knows about the Windows certificates store (contrary to Mercurial itself)
makecert.exe is a bit of a different beast from openssl as it interfaces directly with the machine’s or user’s certificate store (the special place where certificates live a happy life in Windows).
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