views:

1799

answers:

5

I have a solution consisting of 5 projects, each of which compile to separate assemblies. Right now I'm code-signing them, but I'm pretty sure I'm doing it wrong. What's the best practice here?

  • Sign each with a different key; make sure the passwords are different
  • Sign each with a different key; use the same password if you want
  • Sign each with the same key
  • Something else entirely

Basically I'm not quite sure what "signing" does to them, or what the best practices are here, so a more generally discussion would be good. All I really know is that FxCop yelled at me, and it was easy to fix by clicking the "Sign this assembly" checkbox and generating a .pfx file using Visual Studio (2008).

Thanks!

+20  A: 

If your only objective is to stop FxCop from yelling at you, then you have found the best practice.

The best practice for signing your assemblies is something that is completely dependent on your objectives and needs. We would need more information like your intended deployment:

  • For personal use
  • For use on corporate network PC's as a client application
  • Running on a web server
  • Running in SQL Server
  • Downloaded over the internet
  • Sold on a CD in shrink wrap
  • Uploaded straight into a cybernetic brain
  • Etc.

Generally you use code signing to verify that the Assemblies came from a specific trusted source and have not been modified. So each with the same key is fine. Now how that trust and identity is determined is another story.

UPDATE: How this benefits your end users when you are deploying over the web is if you have obtained a software signing certificate from a certificate authority. Then when then download your assemblies they can verify they came from Domenic's Software Emporium, and they haven't been modified or corrupted along the way. You will also want to sign the installer when it is downloaded. This prevents the warning that some browsers display that it has been obtained from an unknown source.

Note, you will pay for a software signing certificate. What you get is they become the trusted 3rd party who verifies you are who you say you are. This works because of a web of trust that traces its way back to a root certificate that is installed in their operating system. There are a few certificate authorities to choose from, but you will want to make sure they are supported by the root certificates on the target operating system.

Jim McKeeth
Very well explained.
GONeale
+3  A: 

Signing is used to uniquely identify an assembly. More details here: http://msdn.microsoft.com/en-us/library/ms247123(VS.80).aspx

In terms of best practice, it's fine to use the same key as long as the assemblies have different names.

Martin Clarke
+1  A: 

It helps because the executable is expecting a strongly named assembly. It stops anyone maliciously substituting in another assembly for one of yours. Also the user might grant an assembly CAS permissions based on the strong name.

I don't think you should be distributing the .pfx file, you keep that safe for resigning the assembly.

Martin Clarke
+2  A: 

The most obvious difference between signed and unsigned assemblies is in a ClickOnce application. If you don't sign it, then users will get a scary "Unknown Publisher" warning dialog the first time they run your application. If you've signed it with a certificate from a trusted authority, then they see a dialog that's less scary. As far as I know, signing with a certificate you generate yourself doesn't affect the "Unknown Publisher" warning. Instant SSL from Comodo has examples of the dialogs.

There are some subtler differences. You have to sign an assembly before it can be installed in the global assembly cache (GAC) where it can be shared by multiple applications. Signing is integral to code access security (CAS), but I haven't found anyone who could get CAS working. I'm pretty sure that both the GAC and CAS work fine with certificates you generate yourself.

Don Kirkby
+1  A: 

It is important to keep your pfx file secret as it contains the private key.

If that key is made available to others then anyone can sign assemblies or programs that masquerade as you.

To associate your name with your assemblies (in the eyes of Windows) you'll need to get a digital certificate (The portion of the pfx containing your name) signed by a trusted authority.

Actually you'll get a new certificate, but with the same information.

You'll have to pay for this certificate (probably annually) but the certificate authority will effectively vouch for your existence (after you've faxed them copies of your passport or driver's permit and a domestic bill)

koregan