I and another guy are developing an add-in project for PowerPoint using C# and VSTO. Our project is being kept in a repository and every time when one of us gets a newest version from the repository, updated by another one, he gets a compiler problem with signing. Up to now, we solved this compiler problem by generating a test certificate on the corresponding machine every time after updating from repository.
My question is: Is it possible to avoid somehow this every-time generating of a test certificate after taking the solution, compilable on other machine, from the repository in order to have it compilable on both machines?
We tried everything:
We used the same .pfx file for both of our PC's (i.e. we sent this file to the repository).
We tried to uncheck the checkbox "Sign the ClickOnce Manifest" in the Properties window of the Solution and to remove the .pfx file at all.
We tried to use our own .pfx files with putting them into the ignore list.
But there was no result!
We have a similar scenario and we are doing the following:
'Sign the ClickOnce manifest' is signed with a locally generated .pfx key that is checked into the repository.
The assembly is signed with a strong name key.
On the build server the manifest is re-signed using the company's digital certificate for deployment using the instructions provided in this article - http://blogs.msdn.com/b/vsto/archive/2009/04/29/signing-and-re-signing-manifests-in-clickonce.aspx
Let me answer my own question. The solution is probably found. The steps are the following:
One developer should generate a new .pfx file defining the password. As a result, he can already develop the add-in correctly, on his machine; but other developer still can not, on their machines.
Using the same tab of the project's "Properties" window, this developer has to select the same .pfx file with the "Select from File..." button, giving the password.
The .pfx file should be sent to the repository (i.e. one shouldn't include it into the ignore list). As a result, other developers will not be required to generate anytime other .pfx files anymore.
We are ready!
The "magic" is that knowing the password by all developers is crucial. When the .pfx file is added to the project as it is described in the item 2, it means that all developers know the password.
Related
I am trying to get the signing working with TFS 2010. I already imported the .pfx File in the Personal Store for the Build Computer. I read somewhere i have to do this for the account the build service is running under. But i don't know how i can do this for "NetworkService", which is the account under which my build service is running.
The error message i am getting of MSBuild:
Unable to find manifest signing certificate in the certificate store.
I read somewhere i have to use the sn -i mycert.pfx VS_XXX but i have no idea where to get the VS_XXX from?
The only working solution for me seems to use another user account for this. In my case I needed a valid domain user. Because the user needs to have the correct rights for the team foundation server.
I logged in with this user on the build machine and added the certificate to my certificates (you should be able to do this by double clicking it).
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.
Having trouble with ClickOnce manifests and our build server.
We have a .p12 code signing certificate (which is the same as a .pfx). I can assign this certificate on a developer machine in:
Visual Studio->Project->Properties->Signing->Select from file, then
enter the password for the certificate.
Everything builds/publishes fine locally.
However when checking in all files to our TFS build server the automatic build generates this error:
Cannot import the following key file: . The key file may be password
protected. To correct this, try to import the certificate again or
import the certificate manually into the current user’s personal
certificate store.
Is there a way to pass in the password to the build definition so that the built assembly is signed?
Also each developer who does a 'get latest' currently needs to re-sign the assembly with the correct password each time, is there a better way?
Note:
The build server does not have Visual Studio.
I have tried manually importing the certificate, under the account that the build runs on, to the personal certificates folder.
This is what fixed my problem:
1 ) Logon as the TFS build controller account and install the certificates manually there.
2) With some older certificates there can be a problem with the root authorisation (chaining), in this case download the root certificate from your certificate issuer, and possibly an intermediate certificate.
3) Make sure the computer/virtual machine that is running the service "Visual Studio Team Foundation Build Service Host" is running under an account that has the certificates installed. In our case this is the same as the build controller account.
I have a WCF project in Visual Studio that I need to deploy to a client's test server. I was on the brink of declaring "Mission Accomplished" when I realized that I have no idea how to take my project from Visual Studio 2010 to something that I can deploy on the client's server.
My gist of this problem is that we use a makefile to do building and packaging when deploying to the client. This means that I need a command-line executable to do whatever it is that I need to do to deploy my WCF service. I did discover right-clicking the project and selecting "Build Deployment Package", but since I need to execute via command-line, I don't think this is going to help much.
The bonus second part of this problem is that, once I get the packaged file the client's server, I'm not sure what to do with it. Now, if I knew what to expect from the packaged deployment file, I might have a better idea, but until then, it's all just speculation.
OK, here is what I came up with.
Packaging
First, the packaging. Use msbuild. Something like this (apparently you need to use a v4 or better version of .NET for it to succeed):
C:/Windows/Microsoft.NET/Framework/v4.0.30319/msbuild.exe {project_file} /t:package /target:Build /p:PlatformTarget=x86;
Fairly easy, right?
Deployment
Now, the bonus part of the question, the deployment. This consists of the easy part and the hard part. The easy part was getting the .zip file created with msbuild.exe added into IIS. I found 2 possibilities.
Commandline
The first is the command-line, which gave me issues (something about being unable to cast 'Microsoft.Web.Deployment.DeploymentProviderOptions' to type 'Microsoft.Web.Deployment.DeploymentProviderOptions' --- I KNOW, RIGHT?). Anyway, this is the command-line I used. It may help someone, or it may not. Again, I had issues with it.
c:\inetpub\wwwroot>"c:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -presync:runCommand="md c:\inetpub\wwwroot\{MyWCFCodeDest} & c:\windows\system32\inetsrv\appcmd add site /name:{MyWCFCodeDest} /id:22 bindings:http/*:54095: /physicalPath:c:\inetpub\wwwroot\{MyWCFCodeDest}" -source:package={ZipFileFromMSBuild.exe} -dest:auto -setParam:"IIS Web Application Name"="{MyIISName}"
UI
OK, so I decided I would be happy with using the second way. It's by far the easiest if you don't care about automation. Open up IIS Manager, right-click the computer OR the website (depending on whether you want it as its own website or an application in an existing website), Deploy, Import, and follow the wizard to the end.
Errors in Deployment
And now where I spent most of my time. I hit my newly deployed .svc file and get an error. This error involves the certificate I was using. Now, maybe not all deployments will have to worry about this, but mine did. The error was lengthy, something about "keyset does not exist" and "cannot be activated due to an exception during compilation" and "may not have a private key that is capable of key exchange or the process may not have access rights for the private key". I tried a bunch of stuff, including using mmc to re-import certs and makecert to recreate both my CA and my personal cert. None of that was the problem for me (ymmv). Finally, I focused on user rights. I found that if I gave the Everyone user permission to the private key for the cert (the cert needs to have a private key), everything worked. Obviously not a solution I want for a client, so I hunted down the correct user to give rights to. Surprisingly, this took a while. Various websites had me adding Network Service, ASPNET, current user, the user specified in machine.config (which is in the .NET directory somewhere), IIS_{MachineName}... none of these worked. The one I had to add was IIS_IUSRS.
So, a handful of caviats that may help your sanity when you scream at your monitor that this isn't working for you, despite following all the directions. Because apparently IIS changes far too much over time and this stuff does matter:
Windows 7 Ultimate sp1
IIS 7.5.7600.16385
Useful Related Stuff
Also, some commandline tools you may be interested in:
-winhttpcertcfg.exe -l -c LOCAL_MACHINE\My -s "{cert_name}" -- lists the users authorized to access the cert's private key (you can also do it the old fashioned way through file properties); I tried downloading winhttpcertcfg.exe, but it was part of a Windows 2003 package that gives warnings about not being compatible (not sure if it came from my attempt to install that file or if it now comes with something I already had installed)
-winhttpcertcfg.exe -g -c LOCALHOST\My -s "{cert_name}" -a IIS_IUSRS -- adds IIS_IUSRS to the permissions for the cert's private key
-findprivatekey.exe My LocalMachine -n "{cert_name}" -- Finds the private key file for the specified cert; for some reason, this is a tool that you have to build in Dev Studio on your own (found in some WCF examples downloaded from Microsoft)
-cacls.exe {private_key_file_for_cert} /E /G "IIS_IUSRS" -- another way to add a user to the private key's permissions
-mmc -- launchs a manager for installed certificate
-makecert -n "CN={CertificateAuthorityName}" -r -sv {CertificateAuthorityName}.pvk {CertificateAuthorityName}.cer -- create a certificate authority cert
-makecert -sk {SignedCertName} -iv {CertificateAuthorityName}.pvk -n "CN={SignedCertName}" -ic {CertificateAuthorityName}.cer {SignedCertName}.cer -sr localmachine -ss My -- create a certificate signed by a certificate authority
One last thing: if you want to import your certs using mmc, you need to launch mmc, File->Add/Remove Snapin. Add the Certificates snapin. Import the certificate authority to the Trusted Root Certification Authorities and the certificate signed by the certificate authority to Personal.
Hopefully you have enjoyed your ride here. Please wait for the browser to come to a complete stop before exiting, and please remember to take any personal items with you.
Additional Discoveries
When it came time to deploy everything to a test server (rather than my development machine), I didn't expect all the hassles that I encountered. I'm documenting these here, again, in an effort to help some other poor, lost soul (or myself at a later date).
-This one should have bee obvious: FindPrivateKey.exe wasn't on the server. I had to jump through some hoops to get it there. ymmv.
-Only the client 4.0 version of .NET had been installed on the server. By the time I discovered this AND realized it was a problem, a few hours had passed. Discovery of the installed .NET versions came courtesy of netfx_setupverifier, which I got from one of Microsoft's websites. The client version doesn't include all the WCF stuff.
-IIS needed some additional settings (files found in the .NET Framework version directory, run from the commandline):
aspnet_regiis.exe -i -enable
ServiceModelReg.exe -r
-cacls.exe informed me that it was deprecated and that I should use icacls.exe. The commandline for icacls is something like:
icacls.exe {private_key_file_for_cert} /GRANT "IIS_IUSRS":R (note, didn't exactly work for me, but you can always just go to the {private_key_file_for_cert} file, probably in ProgramData\Microsoft\Crypto\RSA\MachineKeys, and give permissions via Explorer - right-click - properties)
-You may need to add a handler mapping for the WCF. I highly recommend having it running under an Application Pool that is .NET v4.0.
I have registered for the Safari Development Program and have a valid Apple ID. I've followed all the steps given by Apple.
The problem is that Windows XP (Service Pack 2) does not recognize the command 'certreq', whereas the instructions said it would work on any Windows machine.
However, the command 'certreq' was working on Windows Vista on the machine of my co-worker's, I downloaded the certificate (the .cer file) and installed it and Safari detected it.
However, I don't have Windows Vista.
I installed Windows 7 now on my machine, the command 'certreq' works and I have the Safari Extension Certificate (the .cer file) but when I open Safari's Extension Builder, my certificate does not appear there.
I entered mmc in Start --> Run and checked if the certificate was installed there. It was in the 'Other People' but not in 'Personal'.
Even on Internet Explorer 7+, when I go to Tools --> Internet Options --> Content (Tab) --> Certificates, the certificate is not there in the Personal tab, (WHEREAS IT GOT INSTALLED IN THE PERSONAL FOLDER AUTOMATICALLY IN WINDOWS VISTA). I tried importing the certificate (the .cer file) into the Peronal folder, the import is successful but still neither does it appear in the personal folder nor does Safari recognize/detect it when I go to the Extension Builder.
ANY HELP?!
I need to make an extension for my office project and the deadline is approaching. I really need to get it done.
Thanks a million in anticipation.
I was facing the similar problem. After struggling a lot the following worked for me:
Install (Windows Server 2003 service pack 2) Administration Tools pack as shown on “Generate a Certificate Signing Request” screen shown by Safari Extension Certificate assistant: http://www.microsoft.com/download/en/confirmation.aspx?id=6315
Install IIS resource kit for SelfSSL- http://www.microsoft.com/download/en/confirmation.aspx?id=17275
As indicated by Safari Extension certificate assistant, save the following as certreq.txt --https://devimages.apple.com.edgekey.net/safari/files/certreq.txt
Run cmd, and then change directory to where you saved certreq.txt
On command prompt type: certreq –new certreq.txt newcsr.pem
Press Continue on the Safari Assistant screen, and upload this newcsr.pem
It will generate a certificate that you need to install by double-clicking on the installed file.
You are done!
Go to Develop (in Safari menu bar)>> Show Extension Builder >> Click + and select new extension.
By generating the cert request on another machine you don't have the private key associated with the cert on your own. Generate a cert request on your Win7 machine now, go get a new cert from Apple, and it should work fine.
To use the certificate on Windows, I needed to click on the file that was created (safari_identity.cer). That installed the certificate in the Windows Certificate store. Rrun certmgr.msc and look under the Personal..Certificates folder to see it. My installed cert looked something like this in the Microsoft Management Console for Certificates: "Safari Developer: (xxxxxxxxxxx) me#zzz.com".
this is an answer for Mac users who may be experiencing this problem.
Once you install your certificate, double click it, go under Trust, and set Always Trust for When using this certificate. Your certificate should work then.
It's got something to do with the private key - On me Vista it says CertReq: Request Created and it installs fine, but then on Windows 7 it just creates the file and when you look at the info before/after install it doesn't display that it is associated with the private key on the computer. Very confused I am.
when you enter something like "certmgr.msc" in the run command in window, you will get to see something like this:
So using the certificate consists of the following steps:
first save the file and run the command in cmdd.exe as directed in the developer certificate generator in extension certificate developer.
when you are done, check the certmgr [shown above in the image] and see a certificate named safari developer installed somewhere near Certificate Enrollment Requests. cut the certificate and paste one copy inside trusted root certification Authorities and another inside Personal.
then generate the csr file and install the file inside Personal folder and trusted root certification Authorities folder.
extension builder will recognize the certificate.
Best of luck.
If the certificate has an incomplete chain, it may be necessary to install the certificates on Apple's certificate page . I believe "Worldwide Developer Relations" (and possibly the 2 root certificates) are necessary for Safari Development.