Cannot import the keyfile 'blah.pfx' - err

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

To resolve this problem in Visual Studio 2012, I right click the project, properties -> "signing", and then uncheck the "Sign the ClickOnce manifests".

Answer 4

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.

Answer 5

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

Answer 6

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:

1. 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).
2. 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:

1. 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!
2. Delete the existing certificate from the crypto store (stlll using the MMC).
3. Open a CMD prompt.
4. Import the PFX file using this command:
   1. certutil -importPFX -user <pfxfilename> AT_SIGNATURE
   2. 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.