What is special about a code signing certificate?

Question

Is it different from any other certificate I can generate via makecert or buy from some authority?

Answer 1

It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.

If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.

More here:

http://en.wikipedia.org/wiki/Root_certificate

Answer 2

But is there any difference - can I use a certificate I created for doing SSL for signing an assembly too?

Answer 3

The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).

The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.

Microsoft has a good reference for an introduction to the signing process.

Answer 4

I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.

There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:

• Client authentication
• Email protection
• Server authentication
• Code signing
• Time stamp signing
• IPSec
• Other

Answer 5

Thanks but no-one has yet answered what the physical difference is - why doesn't one cert fit all cases?

Aren't they all just some unique key that says "some commercial company is prepared to vouch that this is really me", because I gave them money (and why does each one come with a different price tag)?

Answer 6

To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.

Answer 7

When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.

There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.

Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.

Answer 8

See here: http://stackoverflow.com/questions/78869/java-code-signing-certificatessame-as-ssl-certificate

Answer 9

As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.

Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.

They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.

You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.

For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.