I'm trying to create an MSIX installation for a small WPF desktop application. I don't need to publish to the store, just "sideloading".
I have a digital certificate, since MSIX requires one. I've installed the certificate on my machine, both for the Current User and the Local Machine.
When I click the "Choose Certificate" button, and then "select from store" the only certificate I see is the test certificate I created myself. I would expect to see "more options" or something like that which would allow me to choose whichever certificate I want.
When I click "Select from file", I get an error that says: "The manifest Designer could not import the certificate. The certificate you selected is not valid for signing because it is either expired or has another issue".
Initially, the "Issued To" value had a comma in it, which my research led me to believe would not work. So I had the certificate authority re-issue it without the comma. I got the same results.
Documentation is very sparse, but what I have seen indicates that I'm doing everything correctly. Any help would be appreciated.
Thanks,
Geoff Callaghan
Related
I want to sign an Oracle VirtualBox Virtual Appliance, an OVA file. I am looking for instructions.
I have had extensive conversations with Comodo and Sectigo. They don't know how and had trouble even understanding the question.
When I load my VM in VirtualBox it says that it is unsigned but gives no information as to how to correct that.
I have a code signing certificate, and I have no trouble signing and timestamping an executable file:
signtool sign /t http://timestamp.comodoca.com t_hello.exe
Done Adding Additional Store
Successfully signed: t_hello.exe
Attempting with an .ova file gives an error:
signtool sign /t http://timestamp.comodoca.com ACoreTpl.ova
Done Adding Additional Store
SignTool Error: This file format cannot be signed because it is not recognized.
SignTool Error: An error occurred while attempting to sign: ACoreTpl.ova
I took a shot at downloading a tool from VMWare, but it did not work on my VirtualBox appliance. It just gave error messages.
Unless the error message is meaningless and just hardcoded in VirtualBox, there is code inspecting something. I really don't want to go fishing through the code, but at this point it seems like I might have to.
The purpose of this exercise is so that I can publish a working system as a virtual appliance that is 'known good' and can be verified as the real thing when it loads.
[Note: There are images in the document I pasted this from, but they would not paste in here.]
I was able to muddle through a work-around. The workaround involves getting a tool from VMWare (ovftool.exe), which seems a bit strange. It allows the import of the OVA, showing the certificate and marking it as 'safe'. It still has a couple of issues. One is an annoying warning message issued while creating the signed file, for which I was unable to find a cure. The other is that it does not seem to contact a timeserver to timestamp the file. Presumably that means that when the signing certificate expires, you get warnings again when loading.
I would still like to know how you are supposed to do it properly according to Oracle. Surely, Oracle is not using VMWare's software to sign their Virtual Appliances.
This is my journey under Windows 10. At the end, I have a publishable appliance.
You need a virtual appliance (*.ova)
You need a signing certificate.
You need to have OpenSSL installed.
You need the program ovftool.exe from VMWare
To get the .ova file, you need to export one of your VMs as a virtual appliance:
Open the export virtual appliance dialog:
File->Export Appliance [Alternatively E]
Choose the virtual machine to export. Fill in whatever Virtual system settings apply.
For appliance settings, set the Format to Open Virtualization Format 1.0
Make sure the 'Write Manifest file' checkbox is checked.
Click on the button to write file.
You should have the signing certificate installed in the certificate store. If you don't have this already, you need to consult your certificate provider.
To get the signing certificate in a usable form, you have to jump through a few hoops to get an old-timey Privacy Enhanced Mail (PEM) file.
You need to get the certificate into a file first.
Start the Certificate Manager by running certmgr.msc
Open Personal->Certificates and right-click on your signing certificate
Open the All tasks menu and choose Export
This should open the Certificate Export Wizard
Click [Next]
Choose the radio button marked "Yes, export the private key"
Click [Next]
Choose "Personal Information Exchange - PKCS (.PFX)"
Check "Include all certificates in the certification path if possible"
Check "Export all extended properties"
Check "Enable certificate privacy"
Click [Next]
Check the Password checkbox, and enter and confirm a password [using password "IMPPass" in this example]
Change the Encryption dropdown to AES256-SHA256
Click [Next]
Assign the filename and path for the exported certificate. In this example, I called it "MyCert". Note that you don't put the file extension on the name here. The Certificate Export Wizard adds it when it writes the file. You should save it on the path where you saved the OVA file.
Click [Next]
Review settings and Click
It should pop up a message box saying the export was successful. Dismiss it by clicking on the button.
You need to do the next steps at the command line.
Open a console window.
Change to the directory where you have saved your OVA and PFX files.
cd c:<yoursavelocation>
You now need to convert the certificate to a form that can be used (.pem). To do this, you need to use OpenSSL. Here is the form of the command:
openssl pkcs12 -in MyCert.pfx -out MyCert.pem
Respond to the prompts for Import Password and PEM pass phrase:
Enter Import Password: IMPPass
Enter PEM pass phrase: PEMPass
Verifying - Enter PEM pass phrase: PEMPass
Finally, you can sign the exported OVA with ovftool with a command like this:
ovftool --privateKey=MyCert.pem --shaAlgorithm=SHA1 DamnSmall.ova DSL.ova
Opening OVA source: DamnSmall.ova
Opening OVA target: DSL.ova
Writing OVA package: DSL.ova
Transfer Completed
The manifest validates
Enter passphrase for MyCert.pem: PEMPass
A warning is issued here, but it will not interfere with the signing.
Warning:
No supported manifest(sha1, sha256, sha512) entry found for: 'DamnSmall-disk001.vmdk'.
Completed successfully
At this point, there should be a signed file called DSL.ova. It will indicate that when imported in VirtualBox.
To test, import the newly created and signed OVA file. Open the import dialog:
File->Import Appliance or alternatively I
Enter the path and name of the signed Virtual Appliance.
Click [Next]
The Appliance settings dialog should have text in the bottom left corner indicating that you have signed the appliance, and that it is trusted.
Appliance is signed
Issues were encountered After creating both a Development SSL Certificate, as well as a Production SSL Certificate. In case you're struggling with the procedure, I found this link to be quite helpful:
How to export certificate from Mac OS X to get pair of .cert and .key files ?
The screen shows instructions for creating a Certificate Signing Request (CSR). I Selected "Continue", then selected "Choose File..." and located the .certSigningRequest.
Selected "Generate". Once the certificate was ready, I selected "Done" and then downloaded the generated SSL certificate from the "iOS App ID Settings" screen.
Follow this link as it is pertaining to the bottleneck at hand:
https://www.parse.com/tutorials/ios-push-notifications
You must Double click on the downloaded SSL certificate to install it. Using Keychain Access, click right under "My Certificates", then you must find the certificate you just added.
Right-click on it, select "Export Apple Development IOS Push Services:...", and save it as a .p12 file. The problem is, I don't have the option to export to .p12 as it is grayed out.
How should I proceed?
Turns out all you have to do is select "My Certificates" on the left panel and it enables the .p12 option.
Open your Keychain Access and make sure your certificate is listed under login keychains (left side), then you should be able to see the export to a .p12 file option. If that does not work for you, possibly your certificate is created incorrectly. Try to generate another one.
2021 answer
What worked for me was to open KeyChain Access, under My Certificates tab, select both files, right clic, export 2 items, and the option was available.
I have an application which is making calls to twitter and I need to inspect the traffic so that I can learn more about oAuth.
When I double click the ssl traffic I get a yellow box which prompts me to go and change the options (by the way I am running my app through a proxy).
After having read about using a certificate on my machine which fiddler creates I have clicked the link to let fiddler install certificates on my machine by following these instructions...
http://docs.telerik.com/fiddler/configure-fiddler/tasks/configurefiddlerforwin8
However instead of this happening...
I get this error message...
"unable to configure windows to trust Fiddler Root certificate" here is a screen shot....
When I checked the logs as suggested (although is confusing as I thought the log was to do with each individual request), anyway I saw this...
I have even tried installing the certificate manually no no avail. Hope someone can help me get fiddler/ssl decryption working with windows 8! :-)
UPDATE : In response to Erics questions he made in the below answer...
Hi Eric thanks for replying.
1) A box popped up saying 'Certificate Trust' this is the box I have taken a screen shot of above. It was the box that told me to check the log.
2) I have an account and when I check my users it says I am an Administrator underneath my username.
3) I have tried to run Fiddler as an Administrator to no avail.
I also tried to drag and drop the certificate manually into the certmgr.msc tool and it comes up with a little round cursor with a line through it. Sounds like permissions but I just cant see why as I have full everything....
I finally found a way to workaround cases where group policy tries to limit who you can trust.
METHOD 1
Go into the fiddler HTTPS options and export the root cert to your
desktop.
Open up mmc.exe and add in the certificate widgets for
Local Computer
Import the fiddler certificate into the Third-Party
Root Certificate Store
Go ahead and use fiddler and see it generate new certs and watch your system trust them.
Method 2
Run afoul and bypass an intentional security control.
reg delete HKLM\Software\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots /f
Go back into fiddler HTTP options, and toggle Decrypt HTTPS traffic off and on again. press okay to install the cert in the usual way
maybe run a gpupdate /force to get your setting back to the way your admins intended.
For insight, the problem group policy settings may look something like this:
If you have any Flags value in your registry under Local_Machine \ Software\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots, this lock-down is probably in effect.
#EricLaw - Are you up for maybe changing fiddler to try to import into the third-party store by default? It seems like the "third-party store" may be less subject to lockdown.
This is the best write-up of third-party-store i've seen: http://kreelbits.blogspot.com/2014/02/whats-purpose-of-users-third-party-root.html
I managed to solve a similar problem I was having (in windows 7) by following the instructions here: http://casualtechs.blogspot.com.au/2010/06/problem-when-trying-to-import.html (with the only difference being that we want to add the Fiddler certificate to "Trusted Root Certification Authorities -> Local Computer" instead of the "Trusted Publishers" that is mentioned on that site). My modified steps were:
Obtain the Fiddler root certificate from the "fiddler options" -> "Https" -> "Export root certificate to desktop" menu
Open the certificate (double click on it)
Click on the Install certificate button
Click the "Next" button
Select "Place all certificates in the following store"
Click the "Browse" button
Tick the "Show physical stores" checkbox
Expand the "Trusted Root Certification Authorities" folder
Click "Local Computer"
Click the "OK" button.
Click the "Next" button, then click the "Finish" button
Basically the bit I was missing when trying to import the Fiddler Root certificate was to drill down into the "Local Computer" folder underneath the "Trusted Root Certification Authorities" folder. You will have to make sure that the "Show physical stores" checkbox is ticked as shown below:
The error message in question indicates that your Per-User certificate store does not allow you to put certificates into it. Sometimes this happens if your Corporate Group Policy prevents end-users from trusting certificates. Sometimes it happens if your software configuration has been changed by 3rd party software (E.g. VPN or security clients). Sometimes it happens when there's a corrupt ACL somewhere.
Questions
What dialog box immediately preceded the error message on the Log
tab?
Are you an admin on the box?
If so, if you run Fiddler as Admin and try again does it succeed or fail?
Workarounds
If #3 doesn't work, click the Export root certificate to desktop button. Then launch certmgr.msc using Start > Run. Attempt to drag the certificate from your Desktop into the Trusted Root Certification Authorities folder. What, if any, error messages are shown?
When configuring Telerik's Fiddler to handle HTTPS, I could not get root certificate installed. The error was "Failed to find the root certificate in User Root List". I solved the problem by temporarily turning off WebRoot, my antivirus program, then reattempting to enable HTTPS handling which installs Fiddler's root certificate. You may have to click the Action button on the HTTPS tab to remove/reset previous certificates before being able to create a new certificate.
I reset my certificates by Tool > Options > HTTPs > Action > Reset all certificates but it doesn't work.
This is how I fixed my problem
Restart service CryptSvc.
Right click HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\ProtectedRoots
Permission > Current Windows Users > Full Access
Delete Full Key HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root
Restart Windows and that's it
Ref: https://www.addictivetips.com/windows-tips/fix-chrome-not-working-windows-10/
I need to sign an enterprise Windows Store app I've developed ,so that users can sideload it into their devices.
I'm in the process of obtaining a code signing certificate from GoDaddy. A lot of the next steps are still hazy for me - any additional details will be appreciated.
What I've done so far
The application is tested, and I was able to deploy it on machines that have a developer license.
Purchased a code signing certificate from Daddy but didn't know what to do next (based on past experience I thought I needed to generate a key pair and a certificate signing request on my developer machine)
Called GoDaddy support who said I actually need a driver signing certificate rather than a code signing certificate. The cost was the same so they instantly switched my purchase.
It turns out there is an automatic process for generating a CSR on Windows, but you have to use Internet Explorer for that. Apparently, the cryptographic stuff is somehow handled transparently by Internet Explorer and the GoDaddy website. I would love to know more about what is actually going on there.
As part of the process you need to provide the legal name and official address / phone of the software publisher (my client in this case).
Once you submit the request, it has to be approved by GoDaddy (who should somehow verify that I am authorized by the publisher to sign code on its behalf).
Next steps
I assume GoDaddy will need to receive some documents from the publisher. I'd love to know how that process works and how long it takes.
Once the certificate is issued, I expect there will again be some easy way to install it on my development machine. Question: is there a way to move the keys and the certificate to another machine?
I also expect Visual Studio (I'm using 2012 Express edition for Windows 8) to be able to use the certificate when creating app packages. Will I need to do some special setup for that or will it be straightforward (part of the "Create app package" wizard) ?
Some of the details I've put on the certificate signing request will eventually be visible on the actual certificate (visible to the persons installing the application). Which ones?
After completing the process here are my own answers:
It turns out the GoDaddy support representative was wrong when
advising me to use a driver signing certificate. I needed a code signing certificate.
The certificate does not show the details of the contact person (which are included in the certificate signing request). You can see the certificate details before you submit the request (I missed it initially). In my case the details shown are the company name, city, state and country.
The documentation requirements depend on the company requesting the certificate (in some cases they may not need any documents at all). GoDaddy has very friendly support, so you should can the requirements from them. The process can take a few days to complete (but they may be able to help in doing it faster).
When using Internet Explorer both for the certificate request phase and installation phase, the process is seamless. I believe it uses Microsoft's Certificate Enrollment API (which is also described in this MSDN blog post)
As mentioned by JP Alioto, the process for using the certificate is described in the article "Signing an app package (Windows Store apps)". To use the new certificate in a specific project:
Open the projects .appxmanifest file
Go to the "Packaging" tab
Next to the publisher field, click "Choose Certificate"
In the dialog that pops up click "Configure Certificate" and select the drop down option "Pick from certificate store ..". The certificate should be available as one of the options.
To export a certificate, you can use the following process:
Run certmgr.msc
Locate the certificate
Right-click > All Tasks > Export to launch the certificate export wizard, which has an option to export the private key
Warning: the private key is supposed to be personal and you should protect it. It is probably OK if you copy it to another machine that you control (assuming nobody can snatch it in transit). Sharing it with someone else may be risky. I was not able to find information about how exactly the private key is used by Windows, but it may be a bad idea to have several people share a private key.
To import the certificate and private key from a PFX file, right click on the file in Windows Explorer, and elect "Install PFX". This will launch a straight-forward "Certificate Import Wizard".
Lots of stuff there. :) There are are few documents you need to read:
Deploying Metro style apps to businesses
How to Add and Remove Apps
Signing an app package (Windows Store apps)
Reading and understanding these documents will give you a better idea of what's going on. Are you sure the enterprise you're deploying for does not already have a trusted root certificate that they deploy to their desktop images? If they do, it may be easier to use that private key to sign the app. (The only reason a public certificate authority is recommended is that you will then not have to deploy the certificate to the target machines.)
You can move certificates (and private keys unfortunately) in the evil PFX format which is basically a PKCS #12 portable key file. But, be very careful how you move that file around. It contains both your public key and your encrypted private key.
Microsoft's SmartScreen Filter under Windows 8 is a small developer's worst nightmare.
While I realize the benefits to end users and the effectiveness at stopping malicious programs from installing themselves on end users' computers, I and many other developers would rather not pay the fees for annual renewal of a Code Signing Certificate or, even worse, an EV Code Signing Certificate. Also, when products developed for use in-house are signed with a trusted certificate from an internal CA, stored in the Trusted Publishers store, they still fall prey to the filter's overzealous behavior.
Developers and Administrators used to be able to disable the warnings and prompts by installing a publisher's Code Signing Certificate in the Trusted Publishers store. Creative developers could install their self-signed Code Signing Certificate there when they install a pre-requisite signed and timestamped with a paid-for Authenticode Code Signing Certificate. After that, programs signed by the publisher would be trusted and would not trip the SmartScreen Filter alarms. Essentially, once trusted, a publisher was free from the recurring fees.
The recent changes to the SmartScreen Filter (and its inclusion as an OS "feature" in Windows 8) make it clear Microsoft wants you to buy a code signing certificate instead of creatively working around the problem they've created for you. Has anyone discovered a new method to trust publishers who use their self-signed Code Signing Certificates by default (i.e., not showing the prompts)? Short of turning off the filter completely, what can end users do to let the SmartScreen Filter know to always trust a Self-Signed certificate?
Please note that purchasing a Code Signing Certificate is not an answer to this question. I'm looking for a way to tell SmartScreen Filter to trust a publisher that does not purchase certificates from an outside source, but instead issues their own for use inside their organization.
UPDATE: I think I might have found a workaround! From MSDN, SmartScreen Filter can be disabled on Windows 8 and Internet Explorer 10 for sites listed as Trusted Sites. If someone could verify that this method works for setup programs downloaded and run from a Trusted Site in Windows 8, that would be greatly appreciated and would help a lot of ISV's and in-house development teams. It would also be the workaround needed to answer this question. Trusted Sites can be configured by group policy, so it would be simple from there.
Programmatically, turning off SmartScreen Filter for the Trusted Sites Zone can be achieved by setting either HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2!2301 for the machine or HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2!2301 for the user to 0, and adding the site to be trusted to the Trusted Sites Zone can be done as shown in this question.
Could someone please verify that my proposed workaround functions on Windows 8 for an unsigned or self-signed executable downloaded from a Trusted Site? I'm not using Windows 8 myself, having spent my OS upgrade budget on certificate fees.
To quote from MSDN's website:
Detractors may claim that SmartScreen is “forcing” developers to spend
money on certificates. It should be stressed that EV code signing
certificates are not required to build or maintain reputation with
SmartScreen. Files signed with standard code signing certificates and
even unsigned files continue to build reputation as they have since
Application Reputation was introduced in IE9 last year. However, the
presence of an EV code signing certificate is a strong indicator that
the file was signed by an entity that has passed a rigorous validation
process and was signed with hardware which allows our systems to
establish reputation for that entity more quickly than unsigned or
non-EV code signed programs.
In other words, EV (paid) validation is just one factor in a large algorithm that determines whether the SmartScreen warning is displayed or not. If you have a lot of people that download your program, or if your program download link has not changed in a while, with some work you can get your program not to show the warning. Also, by digitally signing your code, you can increase your Appication Reputation. This is straight from Microsoft's webpage on the topic.
Using a 90 day trial of Windows 8 from Microsoft, I've been able to verify that my workaround does indeed work. If you want to pay for a code signing certificate once and only once instead of paying annual fees, this method should work for you as well, but I can't make any guarantees. My solution is per-machine, but should be easy to convert to work per-user.
This is my solution:
Set up your own certificate infrastructure.
Publish copies of your root CA certificate, any intermediate CA certificates issued by your root, and any code signing certificates issued by your intermediate CA's to your website as .cer files.
Install an SSL certificate on your website that was issued by your Root CA.
Create an installer/downloader application that performs the following tasks:
Installs the root CA certificate (from your website, step 2) into the Trusted Root Certification Authorities store for the end user's machine.
Disables SmartScreen Filter for the Trusted Sites internet zone by setting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2!2301 to 0.
Adds your website to the zone map by adding the registry key(s) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\yourdomain.com\yoursubdomain.
Maps your domain to the Trusted Sites zone by creating a DWORD named https with a value of 2 in the key created in the previous step.
Purchase a code signing certificate from a member of Microsoft's Trusted Root program, preferably an EV certificate.
Before your purchase, make sure the certificate and timestamping scheme used by the CA for your code signing certificate will not result in OID's 1.3.6.1.4.1.311.10.3.13 or 1.3.6.1.4.1.311.10.3.14, as these would make the signature expire when the certificate expires, whether it's timestamped or not.
Sign and timestamp your downloader/installer with the certificate purchased in step 5. Verify the absence of lifetime limitations on the signature. If everything is ok, you can put your purchased code signing certificate in a safe place and lock it away.
Publish your downloader/installer program to your website. Make it a pre-requisite download for all your products.
From this point on, you can use code signing certificates (and other certificates, for that matter) issued by your own internal certificate authorities without SmartScreen Filter being a nuisance.
The worst warning I’ve received using this method so far has been “This type of file could harm your computer.” That's the typical "You're downloading an executable file!" warning. It doesn’t hide the Run option and does not appear for ClickOnce deployments using the bootstrap webpage generated by clicking “Publish” in VS2010.
Thanks for all the comments and links.
I have found a really easy way to bypass the filter even without admin privileges. What you need to do is:
Open notepad
Type in the following line: #%*
Save the file as "SkipSmartScreen.bat" (yes, with the quotes) in the same folder as your app. You can rename the batch file later
To launch your app, drag your exe on to the batch file
This will then bypass smartscreen filter.
Tested on Windows 10 Home, Pro, and Enterprise, and Windows 8 Pro.
How it works:
# - This is just for looks, it hides the name of the command being executed
%* - This expands to all command line arguments passed (e.g. the file you dropped on the batch file
The whole thing: It executes the file through the batch file as if it was a line in the batch file. For some reason, Windows does not do any check on files which are executed from a batch file.
Here is good explanation how to turn off the SmartScreen:
- Windows SmartScreen - Turn On or Off in Windows 8
- Uncheck option in Folder Options
What I used and what worked for me? It was "option one" from first link:
Open the Control Panel (icons view), and click/tap on the Action Center icon.
In the left pane of Action Center, click/tap on the Change Windows SmartScreen settings link.
If prompted by UAC, then click/tap on Yes.
Select (dot) the option for how you want Windows SmartScreen to handle unrecognized programs, then click/tap on OK.
NOTE: The default option is to Get administrator approval before running an unrecognized app from the internet.
When finished, you can close the Action Center if you like.
I hope that this is what you were looking for. :)
Old question but I recently had the same issue where I needed to download a small installation package down to a user's pc for them to execute.
But as always SmartScreen was blocking the download...
A workaround that I discovered is to package your installer file in a .zip (or the likes) and then have the user download this compressed file and execute the installer within.
This is at least the "prettiest" solution that I had to use in my scenario.
This method saves you from having any kind of certificates assigned to your files. You just need your users to trust you, but this will bypass the SmartScreen Filter.
I hope this can be used as a workaround for your issue.