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.
Related
I am trying to run certutil -repairstore and keep getting prompted for a smart card. This is a VM on AWS and a smart card is not an option. Any thoughts on how to bypass the smart card and get the repair to complete are appreciated
One of the other answers touched on it, but I wanted to add some context/detail as well as I spent a lot of time searching for the root of this problem. Killing the smart card-related services did not work, nor did disabling the related policy with gpedit.
When you run certutil with the -repairstore option, Windows runs through its list of CSPs (Configuration Service Providers), one of which is the "Microsoft Smart Card Key Storage Provider" - that's the one that causes the prompt to enter your smart card. As the above answer stated, the most likely cause is that you are attempting to install a certificate file (.crt, .cer, .pem, etc.) that does not have a corresponding key on the VM, so Windows is cycling through the various CSPs looking for a valid key but cannot find one. There are two possible solutions to this problem:
You should generate your CSR (Certificate Signing Request) through IIS > Server Certificates > Create Certificate Request. This will ensure that the key is generated locally and the appropriate key store is aware of it. Use that CSR to get your certificate from GoDaddy or whoever your provider is, then you should be able to go to IIS > Server Certificates > Complete Certificate Request to install the certificate and avoid certutil altogether.
If you still can't get it to work and are sure the key was generated locally, the -csp option for certutil will allow you to specify which CSP to use when validating the certificate thereby eliminating the need for Windows to try the smart card CSP. You can get the installed CSPs on your system by running certutil -csplist - the "Provider Name" value is what you pass to certutil. For example, certutil -csp "Microsoft Software Key Storage Provider" -repairstore ... would force certutil to validate against the Microsoft Software Key Storage Provider. Make sure you use quotes since there are spaces in the names.
Make sure you make the original certificate request on the same windows server where the domain is hosted. Then complete the request with the p7b provided by the ssl supplier and you won't have any problems.
This question might be a bit old but I came across this error with another cause:
I have mutliple servers trying to import the certificate.
However, the cert request was generated from one server. In that case, I imported to the original server which create the request and export everything from the mmc (including private key) and re-import the pfx file to the over servers.
Try to add -silent to the command
My old Live system (Domino 8.5.3 / Windows 2003) is out on the DMZ and needs to be upgraded to a SHA-2 certificate. So, we have built a new Test server also out in the DMZ (Domino 9.0.1 FP6 / Windows 2008) box to move the site to.
I copied the entire Data directory from the Live over the top of the Test 9.0.1 folder to bring across all the databases and jQuery files etc...
I then followed this procedure to create the new certificate:
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/3rd_Party_SHA-2_with_OpenSSL_and_kyrtool?open
I used the procedure to generate a new CSR which we sent to GoDaddy to have them reKey the SHA-2 for the new Test system.
They returned to CRT files.
1) gd_bundle-g2-g1.crt - This I believe holds the Root and Intermediate certificates. But, I only found two certificates in this.
2) 8e0702e83bd035e9.crt - This has the Site certificate
I extracted the two GoDaddy certificates:
godaddy_root_Base64_x509.cer
GoDaddy_Secure_CA-G2_Base64_X509.cer
Then used the following command to join them all together:
type server.key 8e0702e83bd035e9.crt GoDaddy_Secure_CA-G2_Base64_X509.cer godaddy_root_Base64_x509.cer > hbcln04_server.txt
I followed all the steps in the procedure above. The only difference is that the proceedure shows 2 intermediate certificates but GoDaddy only sent me one.
But, I was able to verify both the Keys and the Certificates as the procedure said.
There were no errors in the process.
I put the new kyr file down in the Data directory with the others and then went to the Website document and changed the reference there to the new kyr filename.
Note, this is a Website document not the Server document.
I even went to the Server document and followed a procedure to Disable and Enable the Website documents just in case the path to the Keyring.kyr file was corrupted.
However, because the new Test box is in the DMZ it is very difficult to test.
So, I have modified the servers Host file to map the certificates domain back to the same box. (Otherwise the DNS would keep taking it back to the Live system.)
There is a question as to whether mapping the domain to the IP of the Test box will work with HTTPS. But, I don't see why not.
But no matter what I do, I can't get the certificate to take hold.
I put in the URL for the site and if it is HTTP it works, But soon as I change it the HTTPS I get this:
This page can’t be displayed
List item Make sure the web address https:_Link_to_site is correct.
List item Look for the page with your search engine.
List item Refresh the page in a few minutes.
I then refresh the page and I get this:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https:_Link_to_site again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
Well unfortunately, I'm the site administrator!
The only things I have seen differ to the procedure is:
1) that I only had 1 intermediate cert and not 2 as in the example.
2) I'm using a Host file to map the domain to the server so it doesn't follow it's usual DNS.
Also note that there are no errors in the log. We did have a few around the Access to the Key files. The kyr file was fine, but the sth file had restricted access. This has been corrected now.
At the moment, I don't know where to even look for an error or what to turn on to see the error.
It seems the certificate just doesn't load.
Please help.
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.
When connecting to the mail server via the email client, we are forced to use SSL. Yet, we only have a self-signed certificate which the IT dept wants us to trust.
What are the real security repercussions?
Assuming the root key doesn't leak, which would break down the whole company CA system, the only issue specific to this use of a self signed certificate is distribution; a certificate authority certificate is normally already on any computer that needs a connection to the server, while this certificate needs to be distributed manually.
If a new computer needs a connection to the server and does not have the certificate, there is no real security if you connect anyway and just accept the certificate. For it to be of any use, it needs to already exist on the computer.
Just as the other two have said, it basically relies on how much you trust your company, which is a factor anyway, so it's likely not a big deal (though they could easily get a free SSL certificate from startcom, so I have no idea why they would insist on a self-signed one).
But as Paul outlined with his example, it also matters if they have you install their own root certificate on your computer; if they don't and instead ask you to click through warning boxes each time, I would suggest speaking up, and emailing a link to this page to your company's IT department.
This is a more complex question than it might appear. The short answer is that if they are following best practices with regard to protecting their self-signed root CA and deploying the root to client machines (incredibly important!) then there is no additional risk beyond that normally incurred with X509 PKI.
The longer answer is, as usual, "it depends what corners they cut". Here's a scenario under which the risk is higher...
Your company does not install the self-signed root directly on
employee laptops. When asked about this oversight they say "that's a
real PITA in a heterogenous computing environment". This (depending on
client and other factors) forces you to choose to click "continue"
through an untrusted dialog each time you launch the client. Big deal
right? It's still encrypted. One day you're in Madrid, enjoying room
service in a five star hotel (as a rising star within the company you
get the poshest assignments) and you open your laptop up to get some
work done...
You always connect to the VPN, but you left your mail client open last
time you put the laptop to sleep and it throws up the same annoying
warning it always shows when you open it. You swiftly click through
the dialog because you've been trained by your IT dept to do so. Sadly,
this time it's a different cert. If you had inspected it directly (you
have a photographic memory and love doing comparisons of base64
encoded public keys) you wouldn't have clicked through, but you were
in a hurry and now the unscrupulous hotel manager running the hotel
capture portal knows your email login and password (p#ssw0rd1).
Unfortunately, you use p#ssw0rd1 on all sorts of other websites, so
you find your reddit, amazon, and even stackoverflow accounts swiftly
compromised. Worse yet, your boss gets an email from "you" with an
obscene rant and notice of resignation. All because you clicked
through that innocuous dialog you've clicked through a thousand times
before.
This (unlikely) scenario is possible when blindly clicking through "untrusted cert" dialogs. Users can (hopefully) be trained to avoid this by telling them not to click through such dialogs and by adding the corporate CA to the trusted roots list of your OS/browser or using a trusted public CA.
It's wrong if you are expected to do anything about it such as click dialog boxes accepting certificates.
If they are doing their job properly they should distribute the certificate internally such that all required network elements already trust it, e.g. browsers, mail user agents, applications, ...
In other words, if you know about it, it's wrong.
Is there a custom SSL certificate authority I can add to my browser?
We use lots of internal urls like
http://www.somproject.somebranch/ for working on individual branches
It would be cool if there was some service I could add to my browser/OS which would let me use a single cert (or easily generate certs) for non-real domains. Does this exist, or is this just a #firstworldproblem?
The point of a custom CA is that you have to create it yourself (by being the holder of the private key for the CA certificate, in particular). Importing just any available CA certificate into your browser would mean that anyone with its private key could issue certificates recognised by your browser (usually for any site, unless there is a specific policy).
There are a few tools to manage a CA:
OpenSSL's CA.pl: it's a script that comes with OpenSSL. It's quite basic but highly configurable (via openssl.cnf).
TinyCA is a front-end to OpenSSL that helps you manage your certificates with a GUI. It's a bit more manageable than CA.pl.
OSX comes with its own interface in Keychain.app.
There are a number of other tools listed in this Security.SE question: EJBCA, OpenCA and XCA.
Most of the hard work is the administrative part (not so much sysadmin, but paperwork) in general. If it's just for you, EJBCA or OpenCA might be overkill.