ClickOnce application signed with purchased CA shows "Unknown Publisher" - visual-studio

I know this question has been asked a lot. I already tried many of the solutions in other questions, but is not working.
The application target framework is 4.5.2.
I'm working on Windows 7 with Visual Studio Community 2017.
The certificate is a code signing certificate from Sectigo. Standard version (not EV).
I'm using the Signing tab on Project properties to sign the application.
I'm publishing to a folder in my machine after that I upload the published files to a web server.
When I check the properties of the setup.exe and myApp.exe both are signed and timestamped correctly or at least it seems so.
Also, the myApp.application file in \path\publish_folder\, the \path\publish_folder\Application Files\myApp_1_0_0_0\myApp.application file and the \path\publish_folder\Application Files\myApp_1_0_0_0\myApp.exe.manifest have the <publisherIdentity> tag that matches with the certificate.
Everything seems good, even when I download the application and run the setup.exe I get the following warning, which is ok:
When setup.exe is executed is published is presented right but after the setup.exe calls myApp.application then it shows this warning with "Unknown Publisher" and that is the problem:
I tried installing the certificate in the "Trusted Root Certification Authorities" store, as well as in the "Trusted Publishers" store and in the "Personal" store, and publish the application again but the same thing happens.
In other questions said that the visual studio signing tab only sign the manifest but no the executable, as you can see this is not my case (setup.exe and myApp.exe have the digital signatures correctly) but even though I decided to try signing using signtool sign command (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe) and build/publish events as theses answers proposed without luck:
.NET ClickOnce Signing results in "Unknown Publisher"
https://robindotnet.wordpress.com/2013/02/24/windows-8-and-clickonce-the-definitive-answer-2/
I think the only thing I'm missing to try is the "sign assembly" option (checkbox in Signing tab in Visual Studio), but when I do it the first time I get the error:
Cannot import the following key file: myKey.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_5578EF228F7A794C myApp
Then the second time I try I get this error:
Error importing key: An attempt was made to reference a token that does not exist

I signed the application and made the publish using Visual Studio Professional 2019 and it worked. Now it still shows the warning but with the publisher correctly in both warnings.

Related

Cannot sign Click Once manifest with code signing certificate via VS options or using signtool

I have a C# Visual Studio 2013 solution (FindAlike) consisting of a number of projects. One of these projects (SimilarFiles) is a class library, including an AddIn Express component, as it implements an MS Office Add-in. When I publish the project as a ClickOnce installer an MS Add-in, a folder is created in the projects Publish folder with the version number of the project containing many files with extension .deploy. Also in the folder above are a file called findalike.application and one called setup.exe. If I copy the contents of the Publish folder to a new machine I can install the MS Add-in by clicking on findalike.application, but I receive a warning about an unknown publisher. If I confirm installation it proceeds satisfactorily.
I have a valid code signing certificate purchased from Comodo, which I use successfully with SignTool to sign a Windows Forms self-extracting installer from another project in the solution.
The option to sign the ClickOnce Manifest in the SimilarFiles project is greyed out, presumably because SimilarFiles is a class library project.
I can specify a code signing certificate by right-clicking on the SimilarFiles project and hovering over the Add-in Express entry and then selecting Signing Options, but the warning message still appears when I attempt the installation on a new machine
How can I use the code signing certificate in order to indicate to the ClickOnce installer on the new machine that the manifest is signed?
Signtool does not work on the setup.exe file, stating that it is not a valid Windows executable. Neither does it work on findalike.application
There is a Signing area on the VS Publish form which I'd missed. If I browse for my Code Signing Certificate (.pfx extension) and select SHA-1 only it signs OK, and install proceeds without warning. Thanks to Add-In Express for this solution.

Self-signed certificate for Visual Studio project not compiling

I have multiple WinForms projects in Visual Studio 2017 for which the one year automated certificates have expired (or will soon.) A new self-signed certificate was created with an expiration date in 2119.
Multiple websites indicate the same steps to create the certificate. One of which is:
Create Cert for use in Visual Studio 2017
I have made attempts to add the PFX when signing the assembly as well as to Sign the ClickOnce Manifest, but still receive the same error messages when compiling:
Importing key file "CompanyFile100.pfx" was canceled. MyApplicationName
Cannot import the following key file: CompanyFile100.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_C0AA3FA6F491AC23 MyApplicationName
In the VS Developer Command Prompt, the command to manually install resulted in a message that the key pair already existed, so I removed and re-added the VS_KEY, but still no luck with compiling.
Error: "Failed to install key pair -- Object already exists."
sn -i CompanyFile100.pfx VS_KEY_C0AA3FA6F491AC23
sn -d VS_KEY_C0AA3FA6F491AC23
VS solutions have been closed and cleaned multiple times. Certificates have been removed via the certificate manager between attempts to recreate them.
Any wisdom to resolution is greatly appreciated. Should the certification be loaded at the Personal or Trusted Root CA level? Is there a limit to usage at the ClickOnce Manifest or the assembly levels?
Thanks in advance.
An interesting, though mildly careless of me, resolution. The VS2017 solution consists of multiple projects. Though the expired certificate was removed from the system, there were several object references to the PFX file defined in multiple projects displayed in the solution explorer. Though the PFX file was deleted behind the scenes, the solution explorer reference had not been. After cleaning up the broken front-end references, the compile completed without difficulty.

VS 2005 Publish - Build Failed - SignTool reported 'Keyset does not exist' - System cannot find file specified (Exception from HRESULT:0X80070002)

VS 2005 Publish - Build Failed - SignTool reported 'Keyset does not exist' -
Facing this error while publishing VB application from VS 2005 ?
I have published my VB application zillion times without any issue but one fine day I ran into this sticky error. Despite of the signing certificate being there, visual studio was unable to find it. I guess this is one of those panic slow motion attacks that VS displays once in a while. After cracking my head for over two hours, finally resolved it without having to re-create a new solution from my application's forms n files, etc..as suggested on some sites.
Previously too I faced this error but I resolved it at that time by creating a new test certificate albeit I had to remove and re-install my application on client machines thereafter to take the new publish as this was a new certificate. This time Visual Studio didn't even allow me to create a new certificate. I got this nasty error when I tried - The System cannot find the file specified in visual studio (Exception from HRESULT:0X80070002). When I tried checking my certificates using certmgr.msc from Run command, I could see that my certificate was there in the Personal Store under Certificates of local current user. I also copied my certificate under trusted certificates folder but to no avail.
After doing four things my issue was finally resolved and I published my same solution happily again.
1. Close your solution. Delete the bin and obj folders of your solution. Remove the following tag lines from your .csproj file. Copy these four lines somewhere as backup.
<ManifestCertificateThumbprint>...</ManifestCertificateThumbprint><ManifestKeyFile>...</ManifestKeyFile><GenerateManifests>...</GenerateManifests><SignManifests>...</SignManifests>
Reopen your solution in VS and clean and re-build. Try Publishing after increasing the version number. It displays a different error that certificate is not found. Now close VS. Re-add those four lines back in the csproj file where they originally were in that file.
2. Reopen your project in VS and under Project Properties in Signing tab, uncheck the "Sign the Click Once manifests" and re-check again. Also do the same for Sign the assembly checkbox. Select the latest .pfx key. Save. Close and re-open Project Properties.
(This pfx is the key generated whenever we create a new certificate. Check the date of the .pfx in project folder to know which was the last one you had created and use that one. Personally I don't give any password while creating new certificate on expiry. )
Also, add your certificate that is present in Personal Store to the Trusted Certificate Store as well using the certmgr.msc console. Simply copy your VS application issued certificate from Personal Certificates folder to Trusted Root Certificates (if there exists a trusted root authority store) in the certificate Manager console panel - the screen that comes after typing certmgr.msc in run command.
3. Now Restart your system. Yes you read that right.
4. Open your project again in VS. Increase the version now and try Publishing. Voila, the publish goes fine.
PS : VS 2005 wakes up a bit late to changes made at manifest level. Also happens sometimes for crystal reports issues :( . So better give some time to reload VS after these changes. :) Step 1 is doing just that to remind visual studio that it needs a certificate and where it finds it usually in the local keystore. So keystore does not exist error does not make sense :) !
Note that I also tried importing my existing project certificate into the local pc's Personal certificate store (list of local store certificates can be checked in certmgr.msc from Run command) using MMC run command's console Snap-In but I get the error that Cryptographic Service Provider is needed to do so and that it is not installed on my system. Also, I can see my certificate is already present there in the Personal certificate store. Its just the Visual Studio forgot where and which one it is. I read somewhere that this can happen if there are too many / multiple publishes from the development machine. :D

Problems installing a VeriSign Certificate in the Certificate Store On Developer Machine

I have a Visual Studio 2010 VSTO Outlook Add In project that was originally created in Visual Studio 2008. The VSTO dll project is signed with a VeriSign Certificate (Pfx file). When the project was created under VS 2008, there were no issues in building it on a new developer machine. Now, under VS 2010, we are getting the following build error:
"Cannot import the following key file: Blah.pfx. The key file may be
password protected. To corrrect this, try to import the certificate
again or manually install the certificate to the Strong Name CSP with
the following key container name: VS_KEY_blahblahblahblah"
For some time I was able to use sn.exe -i to manually install the certificate into the Strong Name CSP, as the error suggests, and all was fine. Now, I get the following cryptic error message when I try to use sn.exe -i to install the certificate:
"Failed to parse the PKCS#12 blob in blah.pfx -- An internal error
occurred"
Does anyone know what causes this failure, and how to fix it? I've seen a couple of posts about setting permissions on the MachineKeys folder under Microsoft/Crypto/RSA, and I've tried that, but still get the same error message.
I ended up opening a Microsoft Premier Support incident for this problem, and it turned out that our Certificate had become corrupted. The solution was to replace it with a new Certificate.

Error 'Object already exists' when signing an assembly using Visual Studio 2008

I'm having the same issue as described in several places, including in Stack Overflow question Visual Studio reporting error "PFX - Error Importing Key / Object already exists".
Most people are having issues on Windows Vista and Windows 7, but in my case I'm running as an administrative user on Windows XP. I've tried all of the solutions I've found and none have worked so far. Since most of the information I'm finding is a few years old: is there some better/current information and maybe a fix that works more often?
My code signing certificate comes from Go Daddy, and it works fine with the SignTool.exe utility. I've signed a lot of EXE files built outside of Visual Studio using SignTool.exe and they all validate correctly.
I tried signing my EXE file for my current project this way, with SignTool.exe, but there appears to be some extra issues related to the ClickOnce publishing I'm trying to use for this project... Hashes are not matching, and ClickOnce is still reporting as "publisher unknown" even though the EXE file is signed.
I still can't get the IDE option to work, but this worked for me and isn't too bad:
Enable "Sign the ClickOnce manifests" in the IDE and select "from store" (selecting from PFX file produces the same "object already exists" error).
Do not check "Sign the assembly".
Add a post build event to run:
c:\signtool.exe sign /f c:\cert.pfx /p password /t http://tsa.starfieldtech.com c:\project\obj\debug\myapp.exe
So basically using the signtool.exe to sign was the trick, but also the manifest needs to be signed (which I let the IDE do), and the other non-obvious part was that you need to sign the EXE file from the OBJ folder, not the BIN folder.
I like this better than the IDE I guess, because with the IDE I think you have to enter your password every time. This way the password is in the post build event command-line.

Resources