Does anyone know how to use code signing certificate for ClickOnce manifest applications in TFS Hosted Controller Build?
Scenario:
I am using Team Foundation Service as a code repository and source control. I have created a build definition using team explorer (Visual Studio 2012).
Build "Process" using Default Template configured to Any CPU|Release
The build is set to "Manual trigger" uses Hosted Build Controller.
TFS build is unsuccessful if my project use Code Signing and Code manifests.
In my solution, two projects having "ClickOnce manifests"
Local build dont have any issues with Code signing and ClickOnce manifests - because Code signing certificate available locally for the build.
But for the same build in TFS, i get the error "Unable to find manifest signing certificate in the certificate store."
(just one error blocking the build)
Question
How can I install the code signing certificate into "TFS Build Service Account" or "Build service user account"?
How can I make the code signing certificate to avail in the virtual build machine's certificate store?
Any alternative to get clean TFS build with Code signing and ClickOnce Manifests?
Have not find the solution yet :( anyone helpful here??
Well I have managed to Sign my ClickOnce manifest in TFS auto build. My certificate was password protected and build server was not able to access the certificate because of that reason. The certificate was not in my personal certificate store hence I had the trouble.
I have imported the certificate into my local machine's personal store and from there i have referenced it for signing the clickonce manifest. When you reference the certificate from the personal store, it will not ask for the password. Hence you can cheat the TFS build and that can now access your code signing certificate..
I have a possible alternative to get a clean build for you.
My company produces a product called ClickOnceMore (www.clickoncemore.net) which can be used to build your ClickOnce manifests rather than MSBuild. It's designed to be easily integrated into a continuous integration build using a command line interface.
To integrate into your build:
* Turn off clickonce in your visual studio solution
* Create a ClickOnceMore project
* To sign the manifests you just need to put the signing certificate in a known folder location and then reference it from the ClickOnceMore project
* Add a new build step in TFS to build the ClickOnceMore project
Hope that helps.
Related
I have developed an STVO add-in for Outlook. This add-in works great on both my personal computers (Office 365) and my company computer (also Office 365).
However, an acquaintance for whom I programmed the add-in (Microsoft Professional Plus 2019) always gets the following error (error message translated into English, it may be slightly different): User-defined functions cannot be used in this application because the certificate used to sign the deployment manifest for XXX or its location is not trusted.
On all other machines I just get a warning that it could be a potential threat, but on the acquaintance's machine the above error message comes up and you can't install it.
What do I need to change so that he can install it too?
Assuming your add-in isn't signed with a trusted certificate but perhaps yours, Outlook doesn't recognize the publisher. For commercial use, it is recommended to sign the code with a "code signin certificate" issued by a trusted authority so that all customer PCs recognize the certificate. Once you have the certificate, follow these simple steps written in the documentation to sign the project How to: Sign Office solutions
I hope I have been helpful
Try to install the certificate before to running the installer - in Windows Explorer, right click on your signed file, Digital Signatures | Details | View Certificate | Install Certificate.
Before a solution can run on user computers, either you must grant trust or users must respond to a trust prompt when they install the solution. To grant trust to the solution, sign the manifests by using a certificate that identifies a known and trusted publisher. See Trust the solution by signing the application and deployment manifests.
You may find the Deploy an Office solution by using ClickOnce article helpful.
I have prepared one setup project for my C# excel add in project. Installing that setup in client PC my add in is installing as unknown publisher.
To resolve this I am adding certificate manually in client PC, but my goal is install my add in as trusted known publisher without adding certificate manually.
Is there any solution to do this?
Thanks in advance.
If you are using an official certificate from a certificate authority you can sign the setup file (ie msi or .exe) using signtool.exe adding a post-build line to your setup project's properties.
signtool sign /f MyCert.pfx /tr http://timestamp.comodoca.com/rfc3161 /v "C:\...\...\MySetupProject.msi
Signtool is automatically installed with visual studio.
In addition to this and prior to building your setup project, you want to sign the add-in's .dll file (also with signtool) and the manifest (with mage).
We recently updated our applications to make use of SHA-256 code-signing with a new certificate. The assemblies are strong name signed using the Sign the assembly option in Visual Studio 2015. The post build event in Visual Studio runs two signtool.exe processes to sign both in SHA-256 and for the legacy SHA-1 certificate:
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /t
<timestampURL> "$(TargetPath)"
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /fd sha256 /tr
<timestampURL> /td sha256 /as /v "$(TargetPath)"
Finally we use Advanced Installer as the installation packager and that too is code-signed on the Digital Signature page using the certificate and timestamp as per the .exe signature.
The final setup file installs and runs on Internet connected Windows machines as you would expect. You can see the certificate is assigned and valid, as well as the certificate chain through the properties of both the setup.exe and the runtime when installed. Furthermore, Windows recognizes the application as from a trusted source and displays the appropriate verified publisher details.
Our customer-base is largely global 100 companies and most of the deployments will be occurring in air-gapped networks. In one of our fist updated deployments in this environment, the certificate could not be verified preventing the installer from completing.
This made sense, because the Windows (2012 server R2) machines were isolated from the Internet and, due to company policies, had Turn off Automatic Root Certificates set to Enabled. This setting can be found in the Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication Settings folder of the MMC application (you need the certificates plugin installed).
When testing on our local test-bed, even machines not connected to the Internet would install the certificates from the setup utility if the above registry setting was the default (Disabled). We could replicate the issue by changing the policy setting to match the customers' (Enabled).
As a workaround, we manually downloaded the Certificate Authorities root certificate and installed it as a Trusted Root Certificate and the install would proceed normally.
When we presented this workaround to the customer, the installation still failed despite the Certificate Authorities root certificate being present in the Trusted Root Certificates of the machine.
The Certificate Authority customer service team recommended that we drop the timestamp from the signing process to allow the install to proceed - and that's the only help they offered (that's another story). However, this means that once the code-signing certificate expires, the application will either cease to run or will present unverified publisher errors.
I'm not totally convinced that this will fix the problem either, because when we tested locally the certificate was still found by the installer and allowed the installation to proceed when the Certificate Authorities root certificate was installed manually.
What I am unable to do is replicate the customers environment to exactly reproduce the problem (which doesn't help). It is almost as if Windows is bypassing the local machine's Trusted Root Certificates store. I am assuming that if this is possible it would be so that Windows can verify against a central root certificate store.
Is this even possible to set up in Windows? If so, where would I find either documentation on this or how is this done?
Am I missing something in the code-signing steps or in my understanding of what should be happening on the installing machine while it is checking the certificate?
I am at a loss as to what to do to get this installer working. What I can't afford to do is keep going back to the customer to get them to keep testing our installs. First-off it's really not the right process to debug, as the supplying vendor it isn't the customers problem to solve, but more importantly, I need our team to understand what is causing this and how to remedy it correctly.
Ideally I don't what to drop the timestamp if I don't have to because down the road this will cause new problems if the software doesn't get upgraded before the certificate expires.
Any and all help much appreciated.
I think one reason a certificate cannot be validated in an airgapped environment may be that revocation cannot be verified. As you may know, a certificate can be revoked, and there are two different protocols to check if it is, CRL and OCSP. Both require network access to the CA that issued the certificate.
Whether revocations are actually checked is governed by policies as described here, and this may cause your issues.
I have written a very simple add-in that adds a button to the ribbon of outlook (C#).
I have spent days trying to get this very simple add-in to install on another machine using the clickonce method.
I have published clickonce to ftp using Visual Studio. All fine so far.
Upon running the resulting vsto (or setup.exe) on a different machine I am getting the error:
'System.Security.SecurityException: Customized functionality in this application will not work because the certificate used to sign the deployment manifest for Add-In or its location is not trusted. Contact your administrator for further assistance.'
I understand the idea behind a certificate being required to remove rogue add-ins being added to Outlook. I have signed the clickonce deployment using a test certificate on my machine.
Simply is it possible, without paying for a third-party certificate, to give a user the clickonce url and them install it without me having to do anything to their machine? (and/or domain etc.) This is ideally to be used by lots of enterprise users. Altering their environment isn't practical.
Many thanks.
Check your certificate chain. Most likely you need to place a copy of the certificate into:
Certificates - Current User\Trusted Root Certification Authorities
...so your "issuer" is trusted in order for your certificate to be trusted.
I have an .net smartclient application OA.Smart.WinUI. I have three .pfx files listed in this project OA.Smart.WinUI_1_TemporaryKey.pfx,OA.Smart.WinUI_2_TemporaryKey.pfx,OA.Smart.WinUI_TemporaryKey.pfx. I want to know which out of these three is being used by this application. I can just find the details by clicking signing tab in properties.
I need this information as i want to change the config file on production server using mageUI.exe. For this i need to sign it again and there is no production certificate. So my understanding is that i need to publish one out of these three files and while signing use the one with which the application has been signed on the development machine.
Please help me out.
You can use MageUI and resign both of your manifest files on the production server. It doesn't matter what they were signed with originally.
I don't know what version of Visual Studio you are using, but in later versions you don't have to sign your manifests at all. That may be an option as well.