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.
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
The error happens when Outlook 2007 VSTO addin is loading at startup. This Windows 7 PC is used by multiple domain users. The error happens only for some of those users. For other users the addin works fine. I assume the unfortunate users do not have some permissions but not sure to where to look at.
Please, help if you hit the same error in the past. Thank you.
The error details are as follows
System.Deployment.Application.InvalidDeploymentException: Exception reading manifest from file:///C:/Program%20Files%20(x86)/<Application folder>/My_OutlookAddin.vsto: the manifest may not be valid or the file could not be opened. ---> System.Deployment.Application.InvalidDeploymentException: Manifest XML signature is not valid. ---> System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.
at System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey)
at System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags verifyFlags)
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
--- End of inner exception stack trace ---
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
at System.Deployment.Application.ManifestReader.FromDocument(String localPath, ManifestType manifestType, Uri sourceUri)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Thank you guys for your feedbacks. I have resolved the puzzle. Firstly, the answers for your questions are as follows. The add-in was installed using setup.exe created in VS 2010 setup project, i.e. it was not a ClickOnce installation. The Visual Studio Tools for Office app was installed on the target PC and also was one of the prerequisites of the setup project. I believe the problem was caused by add-in project's signing certificate and strong name key (snk) file. The certificate was a temporary one issued by a developer. The snk file was created using this temporary certificate. I assume the generated add-in manifest worked only for a certain domain group users. I did not figure this out. What I did was I replaced the temporary certificate with the new one that company recently bought and created a new snk file. However, after deployment, add-in stopped working for all users. The error message was the same. That was when I started to look into the add-in manifest file. What I found was the manifest file created with new certificate had a SHA2 encryption algorithm. But, the VS 2010 can handle only earlier SHA1 version because the highest Framework version that it can target is FW 4. The SHA2 can be used only with FW 4.5 and higher versions. The solution was to use a three years old SHA1 certificate and snk file that were used when the add-in was updated last time in 2013. I found them in the company source code repository. Even the certificate expired last year the add-in manifest still works. By the way, SHA1 encryption algorithm was deprecated from January 2016. Nowadays, all new certificates for signing application are issued with other algorithms like SHA2.
Do the users it's not working for have Visual Studio Tools for Office (VSTO) installed?
See this:
Outlook Add-ins installation
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.
We just upgraded our Visual Studio 2008 projects to Visual Studio 2010. All of our assemblies were strong signed using a Verisign code signing certificate. Since the upgrade we continuously get the following error:
Cannot import the following key file: companyname.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_3E185446540E7F7A
This happens on some developer machines and not others. Some methods used to fix this that worked some of the time include:
Re-installing the key file from Windows Explorer (right click on the PFX file and click Install)
Installing Visual Studio 2010 on a fresh machine for the first time prompts you for the password the first time you open the project, and then it works. On machines upgraded from Visual Studio 2008, you don't get this option.
I've tried using the SN.EXE utility (Strong Name Tool) to register the key with the Strong Name CSP as the error message suggests, but whenever I run the tool with any options using the version that came with Visual Studio 2010, SN.EXE just lists its command line arguments instead of doing anything. This happens regardless of what arguments I supply.
Why is this happening, and what are clear steps to fix it? I'm about to give up on ClickOnce installs and Microsoft code signing.
I was running into this problem as well.
I was able to resolve the issue by running sn -i <KeyFile> <ContainerName> (installs key pair into a named container).
sn is usually installed as part of a Windows SDK. For example C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\sn.exe. Most likely this location is not on the search path for your standard environment. However, the "Developer Command Prompt" installed by Visual Studio adds additional information that usually includes the correct location.
Based on your post that would look like
sn -i companyname.pfx VS_KEY_3E185446540E7F7A
This must be run from the location of your PFX file, if you have the solution loaded in VS 2010 you can simply right click on the pfx file from the solution explorer and choose Open Command Prompt which will launch the .net 2010 cmd prompt tool in the correct directory.
Before running this sn command I did re-install the pfx by right clicking on it and choosing install however that did not work. Just something to note as it might be the combination of both that provided the solution.
I've discovered a fix that helps you be able to build successfully in a multi developer environment:
Instead of changing the password (which causes the .pfx to be changed), reselect the .pfx file from the combobox. This then invokes the password dialog. After entering the password, the project will build OK. Every dev can do this on his local machine without actually modifying the .pfx file.
I'm still having problems getting assemblies to be signed on our build server machine. I'm getting the same error there, however using the sn.exe -i method does not fix the problem for the buildserver.
I had the same issue and deleting the store and reading didn't work. I had to do the following.
Get a copy of OpenSSL. It is available for Windows. Or use a Linux box as they all pretty much all have it.
Run the following to export to a key file:
openssl pkcs12 -in certfile.pfx -out backupcertfile.key
openssl pkcs12 -export -out certfiletosignwith.pfx -keysig -in backupcertfile.key
Then in the project properties you can use the PFX file.
I spoke too soon! Rebuild brought the errors back into play...
I found this works - right click in Solution Explorer and exclude it from the project. Click Show all files, right click and now include it in the project again. Now undo pending changes...
For some reason this sorted it out for me and was relatively painless!
I found that in some cases you should try to delete this key before you install it. So do the following:
sn -d VS_XXXX
sn -i mykey.pfx VS_XXX
VSCommands 2010 (plugin for Visual Studio) can fix this for you automatically - just right-click on error and click Apply Fix from the menu. You can get it from Visual Studio gallery.
After trying all these solutions (and a lot more), I found that the problem lies somewhere else. For people that go through the same misery as me after buying a certificate, I'll share the solution for my problem.
Behavior
I understand that 'sign' applies a strong name and not an authenticode to a DLL or EXE. This is why signtool will work in this case, but 'sign' in Visual studio will not work.
Reason
In the past I've had experience with certificates from Verisign. They have a KeySpec=2 in the certificate - which is used with the 'sign' functionality in Visual Studio. These certificates work fine for both Visual Studio and signtool.
I now bought certificates from Comodo, which have an incorrect KeySpec=1 in the code signing certificates. That means these certificates work fine with signtool (authenticode) but not with strong naming (the sign drop-down).
Solution
There are two ways to solve this issue:
Create a separate certificate for your strong name using sn -k [name].snk. Sign the assembly using the snk and afterwards use signtool with your code signing certificate to do sign the DLL/EXE with the authenticode signature. While this seems strange, from what I understand this is a correct way to deal with certificates, because strong names have a different purpose than authenticode (see also this link for details on how this works).
Import your certificate as KeySpec=2. The procedure for this is detailed here.
Because I want to use multiple strong names, I currently use option (1), although option (2) also works.
To ensure this solution will never get lost in the future, here's the procedure of solution 2:
Using the "Certifiates" MMC export the existing keyset (KeySpec=1) to a PFX file. Note: Please backup this file to a safe location and test if the file can be imported ok on another machine if you really want to play it safe!
Delete the existing certificate from the crypto store (stlll using the MMC).
Open a CMD prompt.
Import the PFX file using this command:
certutil -importPFX -user <pfxfilename> AT_SIGNATURE
Enter the passphrase for the pfx when prompted.
You now should have a keyset/certificate with KeySpec=2. If needed you can now export this into another PFX file using the MMC again.
To resolve this problem in Visual Studio 2012, I right click the project, properties -> "signing", and then uncheck the "Sign the ClickOnce manifests".
I reselected the Key(pfx) file in the "Choose a Strong Name Key File" drop-down box, Then provided password in the "ENTER PASSWORD" Popup Window. Saved my project and did rebuild.build succeeded.
Open Project Properties.
Click on the Signing section.
Where it says ‘Choose a strong name key file:’, reselect the current value from the drop-down box:
Visual Studio will now prompt you for the password. Enter it.
Save your project and do a rebuild.
If get error message:”An attempt was made to reference a token that does not exist” just ignore it and Continue the below steps
Click the ‘Change Password” button:
Enter the original password in all three boxes and click OK. If you’d like to change your password (or if your old password doesn’t meet complexity requirements), you can do so now.
Save your project and do a rebuild.
More Info..
As a workaround, I tried running the Visual Studio 2010 as an administrator, and it worked for me.
I hope this helps.
As the original author of the work around on the connect bug report, there are TWO variants of this message (I've discovered later)
For one variant you use sn.exe (usually if you are doing strong naming) to import the key to the strong naming store.
The other variant for which you use certmgr to import is when you're codesigning for things like click-once deployment (note you can use the same cert for both purposes).
Hope this helps.
Nothing worked for me, but then I went and looked into the certificate manager (mmc.exe). The certificate was not imported in the personal store, so I imported it manually and then the project compiled.
See ClickOnce Manifest Signing and Strong-Name Assembly Signing Using Visual Studio Project Designer's Signing Page, Signing Assemblies.
This Solved my problem:
Open your VS Project
Double click on Package.appxmanifest
Go to Packaging tab
click choose certificate
click configure certificate
select from file and use example.pfx that unity or anything else created
Reselecting key file in a combobox and entering password helps on this for us.
But it is needed to do each time the key file changes and it seems to be not OK.
I had the same problem after moving my Windows installation to an SSD. None of the other solutions worked for me.
My solution was to open the project file in Notepad and remove all references to PFX keys. Once the file is saved, open the solution in Visual Studio. Go to project -> Properties -> Signing. You shouldn't see any keys listed in the 'choose the strong name key file' combo box. In the combo box, browse to the key, select it and your project can now be built.
My problem was that the TFS Build Controller was running as a network service and for some reason I didn't understand why the Visual Studio Build Host service certificates were not being used. I changed the identity of the Visual Studio Build service to something more manageable, made sure it had rights on the TFS server, and manually added the certificates using the MMC.
The problem was also that MSBuild can't add the password protected certificates to the store.
I had a similar issue, but after selecting the pfx in a "Strong name key file" ComboBox and typing the password I still got a similar error (without the container name part):
Cannot import the following key file: companyname.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate
Also, the "Sign the ClickOnce manifests" certificate information panel wasn't populated.
I did "Select from File..." on my pfx, and it solved the problem.
All methods described here didn't help me. But when I deleted the *.pfx file from my project and added it to the assembly's signing again, I built my project with without any error! I can't explain reasons why. But it worked for me.
Okay, this worked for me. Open the old solution/project as an administrator in Visual Studio 2010 and open the new or copied solution/project. As an administrator, remove the copied pfk file in the new Visual Studio 2010 solution/project and go to project properties and unselect it.
With both projects open, copy paste to the new one. Go to project properties and select Build. I opened and closed Visual Studio and also after removing from the new project built it before copying it from the old project and selecting it. I received the error at the start of this post first up when I copied the project and tried to build it.
In my scenario the build service was not using the same user account that I imported the key with using sn.exe.
After changing the account to my administrator account, everything is working just fine.
Unfortunately, no approached mentioned here worked for me. I have to register couple PFX in a docker container and I need to pass the password via command line.
So I re-developed the
sn.exe -i <infile> <container> command in C# using the RSACryptoServiceProvider. The source and the app are on GitHub in
the SnInstallPfx project.
The SnInstallPfx app accepts a PFX key and its password. It computes the key container name (VS_KEY_*) automatically (borrowed from MSBuild source code) and installs it to the strong name CSP.
Usage:
SnInstallPfx.exe <pfx_infile> <pfx_password>
// or pass a container name if the default is not what you need (e.g. C++)
SnInstallPfx.exe <pfx_infile> <pfx_password> <container_name>
I know this is an old question but most answers do not work on other devops system anymore. VS_KEY_xxx is different on VMs so that we cannot use sn.exe.
This is the yaml script I used in GitHub Actions to build my VSTO project, which required ClickOnce. Actually only need two lines of powershell after "run:":
- name: Import certificate
shell: pwsh
run: |
$Secure_String_Pwd = ConvertTo-SecureString "<Password>" -AsPlainText -Force
Import-PfxCertificate -FilePath '${{github.workspace}}\project\project1_TemporaryKey.pfx' -CertStoreLocation Cert:\CurrentUser\My -Password $Secure_String_Pwd
I got the same error.
In my case, I tried all of the above, but I couldn't get the result.
I finally realized that in my case, the reason for the error was that the certificate password was not entered or entered incorrectly. The error disappeared when I entered the password dynamically correctly. successful
For whom is using GitLab runners:
Be sure to run the runner with an account that you can logon to: ./gitlab-runner.exe install --user ".\ENTER-YOUR-USERNAME" --password "ENTER-YOUR-PASSWORD" (I had to stop and uninstall first)
follow this guide to grant the build user permission to login as a service
logon with such build user
use the command suggested in other answers: sn -i certificate.pfx VS_KEY_C***6
the container name is suggested in the failed Job output on GitLab (msbuild output)
In Visual Studio 2019 and a .Net 5 project the solution to this problem for me was to just exclude the .pfx file from my solution and it immediately worked.
I solved this issue for myself by changing the following line in the Visual Studio project's .csproj file:
This threw the 'cannot import' error:
<PropertyGroup>
<SignManifests>true</SignManifests>
</PropertyGroup>
Changing the value to false made the error go away.