0

I'm trying to automate all the build & release process in our company and I'm struggling with a very small step: the PFX key import in the local machine. For example we have a new build machine and the code we want to build is signed during the build via a PFX file that is password-protected. When I run the build in TFS on this machine the build fails with this error

Error MSB3325: 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_03AD4638FE10A12F

Good, as stated here I only have to import the PFX file in the container named VS_KEY_03AD4638FE10A12F...but this is a manual step required after a first failed build occours, and I need it to fail to know the container name to use for the key import via sn.exe.

Instead, I would like to provide a build machine that is already able to compile the code.

How is that container name generated? Is there any way to tell in the source code a fixed container to use so that it does not change each time a new machine is used to build? Or, can we retrieve the key container that will be used before the build so that I add a build step that imports the PFX file? Or moreover, is there any "generic" key container I can use (that will be the same for all the machines)?

Thank you

gvdm
  • 3,006
  • 5
  • 35
  • 73
  • I would look into getting the build process to dynamically obtain it instead of it being part of the environment. You can keep pfx and certificates in source control with different permissions so that only the build service can get it and interact with it (and there are other secure means of passing these secrets around). – daughey Dec 01 '18 at 18:30
  • Hi @daughey. But how do I "get the build process to dynamically obtain it"? Do you know if it is pre-defined anywhere in the build process? – gvdm Dec 03 '18 at 08:00
  • I was thinking of using a pfx file that isn't password protected so it doesn't need installed into the container. Obviously sidestepping the security you get from having a password - so having a different repo or protected part of source control would replace that to a certain extent. – daughey Dec 03 '18 at 18:33
  • Perhaps using sn.exe -c to clear the current container and then again sn.exe -c MyContainerName to create a new one with a well-known name? – daughey Dec 03 '18 at 18:35

1 Answers1

2

You can use the SnInstallPfx.exe. It will determine the container name and import the pfx.

For more information, see the following blog article.

Dan
  • 778
  • 7
  • 18