Sign assembly with .pfx certificate RRS feed

  • Question

  • Hello everyone.

    Recently I got my certificate from Comodo.
    I can easily sign my executables and msi files with signtool.exe without any problem.

    Now the problem: I need to sign my assemblies in each Visual Studio projects. (Visual Studio 2010 on WinXP)

    When I go to Project>Properties>Signing, I flag "Sign the assemly" and chose my certificate.pfx file.
    When I insert the password, I got this error:
    "Cannot find certificate and private key for decryption".

    So I made a clean export of my certificate.pfx file with CertMgr.msc thith the following:
    1) yes, export the private key
    2) none of all personal information exchange checks.

    Then I re-made the Visual Studio signing operations with this new .pfx file.
    But this time, when I insert the password, I got this error:
    "Cannot import the following key file: MyCert.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_xxxxxxx"
    "Importing key file "MyCert.pfx" was canceled."

    So I tried to manually the sn tool (sn -i MyCert.pfx VS_KEY_xxxxxxx), but I only got another error:
    "Failed to install key pair -- Object already exists"

    And later, doing again the procedure, I got another error
    "An attempt was made to reference a token that does not exist"

    I'm out of ideas... please give me some help. Thanks

    Thursday, February 7, 2013 4:24 PM

All replies

  • "Cannot find certificate and private key for decryption".

    Hi DevRex,

    This issue occurs mostly likely the .pfx file cannot include certificate chaining information.

    I'm not sure how did you create the .pfx file. I suggest you to sign the assembly using a new key file created by Visual Studio, see http://msdn.microsoft.com/en-us/library/ms247123(v=vs.110).aspx

    Best Regards,

    Bob Wu
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 8, 2013 8:55 AM
  • Hi there and thanks for your response.

    I didn't create the .pfx certificate, it was given to me from Comodo (certificate authority). I paid for that.

    The link you give to me said:

    1)"The .pfx file cannot include certificate chaining information. (If the .pfx file does include this information, the following import error will occur: "Cannot find the certificate and private key for decryption.")"

    For that point, I already made a clean export of my .pfx certificate (like I write before) with CertMgr.msc, WITHOUT all personal information exchange checks: One of that checks, explicitly says: "Include all certificates in the certification paths if possible".  And I have NOT used that option. So I think it's ok.

    The other point in that article say:

    2)Must have been created using the RSA digital signature process. [In my certificate details, I got "Signature Algorithm" : sha1RSA. I think it's ok]

    3) Must support code signing. If the EKU (Extended Key Usage) or KU (Key Usage) setting for the certificate is set, it must also explicitly contain the Code Signing setting [I have that option, looking in the certificate properties. I think it's ok]

    4) There are no restrictions on expirations.

    This I think, is the critical part: As I know, every certificate given from any authority MUST have a validation period!!!! (1 to 5 years).

    If that point is true, Visual Studio cannot EVER strong name your assemblies with a certificate given to you by ANY certificate authority.

    Can anyone form Microsoft confirm that?

    Thanks for all your help.

    • Edited by DevRex Friday, February 8, 2013 10:01 AM
    Friday, February 8, 2013 9:58 AM
  • Hi DevRex,

    I'm still consult this issue with other engineers. However, I haven't get any response yet. I will post back if get anything.

    Best Regards,

    Bob Wu
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, February 13, 2013 9:37 AM
  • Hello DevRex,

    I recently ran into this EXACT SAME PROBLEM as well.  After scouring the internet and trying everything you'd listed here (from articles I found) and then some, I finally found a WORKAROUND solution using the SignTool.exe program that worked for me - Perhaps it will help you as well!  Here are the steps I took to workaround this problem:

    1. First create a PFX file from the existing PFX file that comodo sent you.  You can do that by following the steps listed here: 

    2. Second, in your Visual Studio CS project file properties (for the EXE you want to sign), under the "Signing" tab, UNCHECK the "Sign the assembly" option.  Instead, the workaround is to manually sign it with a "post-build" call to the "signtool.exe" program.

    3. Third, once the new PFX file has been created, you can verify the Signtool.exe program will indeed sign the EXE file by testing the command (in a VS.NET command prompt).  First place the PFX file in the directory for the code in you VS project.  Then, open the VS command prompt, cd to your code's directory, and then call the following command:

    signtool.exe sign /f MyPfxFileNAme.pfx /p MyPfxFilePassword /t http://timestamp.comodoca.com/authenticode bin\debug\MyExeFile.exe

    (Make sure to fix up the "PFX file name", "password", and "EXE file name" in the command I've given above.) If the command is successful, you should get a message in the command window that says "Successfully signed and timestamped."  However, if you're still skeptical about the EXE file being signed, just go into your "bin\debug" directory, right-click on the EXE file and choose "run as administrator."  When the EXE is opened, you will get the "User Account Control" prompt and the "Verified Publisher" should show your name (and not the value of "unknown").

    4.  Finally, to create a post build event to automatically sign the assembly when the project is built, go into the properties for the CS project file, and on the "Build Events" tab, add the following POST BUILD command (notice this uses build macros to get the build location correct):

    "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)MyPfxFileNAme.pfx" /p MyPfxFilePassword /t http://timestamp.comodoca.com/authenticode "$(TargetDir)$(TargetName).exe"

    (Make sure to fix up the "PFX file name" and "password" in the command I've given above.)  Also, if you get a 9009 error when trying to build the VS solution with this command, check to make sure that all of the files names are correct.

    Anyway, I hope this helps you (and others out).  These steps worked for me as a workaround to using the standard Visual Studio Signing tab in the CS code project's properties.  Best of luck!



    • Edited by Geoffrey G Monday, February 18, 2013 1:10 PM
    Monday, February 18, 2013 11:22 AM
  • @Bob Wu

    Thanks for all the support. I'm waiting for any of your response, either good or bad.


    Thanks for your response, but I think you have confused the problem:

    All the things you have done, are just for Authenticode (signtool). Like I said in the first post, I'm doing everything ok with signtool.

    What I'm trying to do is to use the same .pfx certificate (paid good money from a CA) as Strong Name (sn - visual studio). But it seems it's not possible...

    Monday, February 18, 2013 2:15 PM
  • Hello DevRex,

    Yes, there definitely seems to be issues signing through the VS project.  I was planning to call Comodo today and ask them, had you tried that already?  I'm certain that there is probably just something stupid that I'm not doing correctly otherwise, but no matter what I try, I get the same errors as you listed above and was basically stuck at the "An attempt was made to reference a token that does not exist" error.  Anyway, if I find something out from Comodo, I'll let you know...but it MUST be possible somehow, this is the whole reason you buy a cert like this...

    Best Regards,


    • Edited by Geoffrey G Monday, February 18, 2013 2:30 PM
    Monday, February 18, 2013 2:28 PM
  • Hi again Geoffrey.

    I haven't contacted Comodo for 2 reasons.

    First of all, I think this is a Visual Studio/ Sn.exe problem. Because I got a third-party object (the certificate) that it must be recognized/trusted across the internet. If it's not, what's the entire purpose of the signing?

    The second reason is that I had REALLY HUGE problems with Comodo. From the start to the end of this certificate request, passing through the support.

    Maybe I should ask an official Visual Studio Support, but I think I should pay for that...

    Tuesday, February 19, 2013 12:06 PM
  • I am having the same problem with Comodo, Can you update your status ? What sulotion did you find ? Does the problem was with Comodo/VS/SN ??

    Thank you,


    Thursday, May 2, 2013 10:16 PM
  • No, I haven't found any solution yet.

    If you have the desire and patience to help me, any help is welcome.

    Unfortunately, due to lack of time and resources, the whole problem for me it's now "on hold"...

    Wednesday, May 8, 2013 7:21 AM
  • I have same situation here with VeriSign(Symantec) issued .pfx file and code signing certificate. It for sure contains both private and public keys and has code signing as one of purposes listed.

    It will work just fine for authenticode (signtool) to sign (allow users to identify you as an author of the software) the binaries or ClickOnce manifest e.g. - it will not work for strong name verification signing (checking if the referenced binaries, assemblies are original and not been tampered with).

    Whatever the reason for Microsoft doing this will be after and IF we got answer here from Bob Wu-MT:

    you do not need .sn of .pfx file issued by trusted authority for this if you already signing your software with such trusted authority issued certificate. You can safely use your self-generated certificate(keypare) and .sn file to strong-name.

    Your users will check if they trust the .exe file on base of the fact that it is signed by authority issued certificate, but this .exe is also strong named and only same key strong-named .dll assemblies can be used together with it, so they are 'automatically' bound to your certificate.

    Only risk is in loosing or having your self-generated private key published next with your password. But that is always a disaster in a first place.

    • Edited by Stazis Wednesday, May 22, 2013 3:22 PM
    Wednesday, May 22, 2013 3:09 PM
  • The answer to my problems with Comodo's certificate was to implement the following:


    Thursday, February 20, 2014 8:12 PM
  • I'm a newbie and not a security expert but I found a solution (not able to sign my assembly) to this at <Stack Overflow in a thread named "Signing assemblies with strong name using pfx and visual studio".

    I cannot use link because my account is not verified yet grrr.

    I hope it helps.



    • Proposed as answer by JL.M5 Friday, April 18, 2014 4:14 PM
    Friday, April 18, 2014 4:13 PM
  • Hello.

    The solution is available at Comodo knowledge base:



    Tuesday, August 26, 2014 7:52 AM