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.
Related
I need to install a cert to allow a browser to talk to localhost via our app. The .pfx file created for this purpose works great when imported with the Windows 10 MMC tool. But that's a lot of steps to make our users do manually.
By following the steps in this answer (Install a pfx certificate in a users store in Windows using WiX), I can build an MSI and it runs on the target machine without errors.
However, the cert does not exist in the usual "Certificates - Local Computer" MMC tool, nor can the cert be bound to the app with netsh. After a bit of searching, it turns out the cert is installed "somewhere in IIS", and is only visible in the IIS tool (?!).
Using openssl, I converted the .pfx to a .pem file. When running the MSI, this DOES seem to install the cert to the proper place (?!). However, the cert is missing the private key, so it also can't be bound with netsh ('SSL Certificate add failed, Error 1312').
What on earth is going on, and how can I make Wix install the certificate properly?
Well, I guess I figured it out. I tried running the MSI on a virgin Windows 10 installation, and the .pfx file installed correctly and can be bound ok.
So, my guess is that "something" is checking the local computer to see if IIS is installed, and makes the decision to install the cert in a place that only IIS can see or use it. There's probably a lot more going on behind the scenes, but that's the gist of it.
In summary, use a .pfx file to get the private key, and remember that the installation will only work on computers without IIS installed.
Any windows uwp "experts" here?
I've been researching on the below mentioned topic for a day now as I couldn't believe there is no way that we can distribute our UWP App.
Is it really not possible to distribute an UWP App through a different channel than the store without having to manually run+interact with the powershell script?
Because we can't really do that for our customers everytime. They also do not have admin rights and are not allowed to use the normal windows store.
Just installing the certificate and then running the appxbundle does not work, we always have to run the powershell script in order for it to work... :/
UWP-apps that are not from the store need to signed with a trusted certificate. Otherwise the installation will not be successful.
If your app is correctly signed and the certificate is trusted, you can double-click the .appxbundle to install the app on more recent versions of Windows 10.
The powershell script only needs admin rights because it adds the temporary developer-certificate to your trusted certificates.
First off you need to create a certificate and sign your appx/appxbundle with that.
You have have to install the Certificate on your Clients Machine but for that you need Admin rights.
So you have to give your client the certificate and they have to distribute it via Group Policies.
That way you don't have to install the certificate via the powershell script.
Now you can write a script that will install the Dependencies and Appx on the Machine. For that you don't need admin rights, but side loading must be activated. But like I said the Certificate has to. be installed otherwise you can't not install the App.
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've followed the guidelines and configured fine my desktop for Ad-Hoc distribution (requested certificate from the CA, created the main Certificate with my name, created a provisioning associated to devices, and so on).
Now I have my laptop and I need to configure it with the same account (not creating a team development account, but an admin one). I didn't recreate the certificate from the CA because I already have my valid certificate online (the one associated with the provisioning), and I downloaded it and installed it in my keychain. But if I open Xcode and look for a valid provisioning, it says "profile doesn't match any valid certificate/private key pair in the default keychain".
Do I need to recreate my own certificate every time I switch from my workstation to the one in my office?
When you create a CA it uses a private key on your system. You need to copy that to your laptop in order for XCode to use the CA.
http://developer.apple.com/ios/manage/certificates/team/howto.action (need to be logged in)
Here is a helpful article on the topic:
http://www.buggyprogrammer.co.uk/2010/12/13/sharing-ios-distribution-certificate/
I'm in the process of doing this myself, so I'm not sure if this works, but seems like it should.
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.