[Solved-5 Solutions] Cannot import the keyfile 'blah.pfx' - error 'The keyfile may be password protected'
Error Description:
- After we upgrade our Visual Studio 2008 projects to Visual Studio 2010, 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
Solution 1:
- We will be able to resolve the issue by running
sn -i
(installs key pair into a named container).- sn is usually installed as part of a Windows SDK.
- For example
- Based on your post that would look like
- 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.
Solution 2:
- 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.
Solution 3:
- 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:
- Then in the project properties you can use the PFX file.
Solution 4:
- 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 .
Solution 5:
- 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.