Best Practice for PFX Files in a Multi-Developer Environment

Question

I have spent time sorting through questions like these

with no luck so far. My company has a pfx file from VeriSign that we use. I have it added to my project and entered the password upon adding and then checked my solution in. Then I go to another machine and the project compiles with the following error:

Cannot import the keyfile 'xxx.pfx' - error 'The keyfile may be password protected'

Is there a way around having to enter the password for the PFX file on each development environment? It seems like if I could point my reference to the server location of the PFX file that might solve this issue. However, when I tried to change my .csproj file in notepad from:

<ManifestKeyFile>xxx.pfx</ManifestKeyFile>
to 
<ManifestKeyFile>\\server\VeriSign\xxx.pfx</ManifestKeyFile>

I get an error about illegal characters in the file name.

Any suggestions for how to not have to enter the password on each development environment?

Thanks in advance, Jennifer

Answer 1

Your approach is, ehm, insecure in nature. You should not, never, ever, make a code signing certificate including the password for its private key generally available to all developers in your team.

You should understand that publishing a piece of software is a legally binding action, and your code signing certificate is here to prove the authenticity of that software and establish trust with end-users / customers. Your current practice completely undermines this trust. When you enable just anyone in the company / dev team access to this certificate, it's like telling

“Hey, our managing director is blind, and he will sign any paper without reading it.”

Instead, you should either use an unprotected development certificate issued by an internal CA, or apply delay-signing.

The production code signing certificate should be available only in a controlled, secure, release build environment. It should be imported into the certificate store without private key export enabled. Only trusted people, possibly with adequate legal clauses in their employment contracts, should have access to this release build environment.

Answer 2

I am working on a VSTO add-on for Excel which is signed. I don't know if this applies to your project type or situation.

Visual Studio doesn't actually sign the manifest using the pfx file. It signs it with a certificate that is in the Windows certificate store, which has the thumbprint in the ManifestCertificateThumbprint property.

<PropertyGroup>
    <ManifestKeyFile>some.pfx</ManifestKeyFile>
</PropertyGroup>
<PropertyGroup>
    <ManifestCertificateThumbprint>...</ManifestCertificateThumbprint>
</PropertyGroup>

The ManifestKeyFile is a hint to Visual Studio on where it can find the cert if it's not in the store.

When you create a new VSTO project, it does not contain either of these properties until the first time you build it. On this first build, Visual Studio pushes you into a workflow that creates a cert in the store, sets ManifestCertificateThumbprint, exports the cert to a pfx file, and sets the ManifestKeyFile hint to point to that file. Adding this project to source control causes the second dev to have a different workflow. For her, the ManifestCertificateThumbprint is not in the cert store, so it uses the ManifestKeyFile hint to locate the pfx file in the project, and install that cert to the store, which causes her to enter a password for the pfx file. After the cert is in the store, the pfx file is just cargo in the project.

This workflow is fine. Since it's a temporary, unprotected, local cert, it doesn't really matter if it is shared among devs.

What you might be looking for is this workflow: Use the Select from Store... option on the Signing tab of your project to choose the cert. It will remove the ManifestKeyFile hint. When other devs get the project from source control, they will need to have the cert in their store already, so you can delete the PFX from the project. Essentially, creation and distribution of the temporary dev cert becomes a network admin problem, and not a dev/build problem. There are plenty of ways for admin types to push a cert into the stores of machines on the domain.

In either scenario, the real final production cert should be applied at the last minute of the build machine (after building with the temp dev cert) with a tool like Mage.exe (Manifest Generation and Editing Tool).