8

Most CAs are selling code signing certificates in different "products", like Verisign or Certum:

  • Microsoft Authenticode - "Allows you to sign EXE, OCX, DLL, bla..."

  • Java CodeSign - "Allows you to sign Java code"

  • Software Publisher Certificate - "Allows you to sign software"

Well, I am REALLY confused about this. What is the difference between all these products - except the PRICE? I asked Verisign and other CAs a few times since I am curious, but got no answer.

I got a Authenticode certificate from Certum CA. I enrolled it in Internet Explorer, exported it as PKCS#12 PFX and could sign EXE, DLL, ... as promised.

Now... I tried to import this PFX into Java with keytool, then I tried to sign a JAR. And it worked!

And then there is the mysterious "Software Publisher certificate" as product. I don't know what I can/should sign with that... Mac? Linux? Isn't "Microsoft Authenticode" a Software publisher certificate too? Isn't a EXE "software"? That really confuses me.

So, my question is now: When I have ordered a Microsoft Authenticode cert, is it then illegal to use it to sign e.g. JAR files or if possible any other content? There seems to be no technical difference between these certificates. All of those products should have the same codesigning EKU-OID "1.3.6.1.5.5.7.3.3", which does not make any differences between EXE, JAR, Adobe Air and what the hell also exists around there. So, if all "CodeSigning" certificates are technically equal, why do I have to decide then if I want to be a "Java Developer" or "Windows Developer" or "Software Developer"?

Maybe there are still differences in the certificate? Maybe I get not enough rights in JARs when I use Authenticode-certs for signing?

(PS: I do not use my software commercially!)

Emmanuel Bourg
  • 9,601
  • 3
  • 48
  • 76
Daniel Marschall
  • 113
  • 1
  • 6
  • 1
    You know, dealing with certificates closely (we develop and sell PKI library), I have the same questions and no response. This seems marketing BS, cause as you correctly noticed, key usage is the same and from technical point of view the certificates are the same. Maybe they try to fool some users into buying several different certificates, or issue them directly in applicable format (PKCS#7/PKCS#8, JKS, PKCS#12). – Eugene Mayevski 'Callback Sep 07 '10 at 06:28
  • Thank you for your comment. Well, what do you think? Might a CA revoke my certificate if they find out that I also sign JAR software? I am very unsure if it is according to their legal terms, since there are these "products". – Daniel Marschall Sep 07 '10 at 20:55
  • Sorry for not answering before - your question was not noticed . I am investigating this question again now and for GlobalSign CA there's no indication in their documents that explicitly prohibits use of say Authenticode certificates for Adobe AIR. It can happen, though, that they treat it as violation of Subscriber Agreement (though there's no such restriction set there). So I am having this problem myself now (trying to decide if I need to buy another certificates for different signing types) and have no solution. – Eugene Mayevski 'Callback Nov 03 '10 at 15:36

1 Answers1

2

There is no technical difference as you guessed, the certificate provided works for any code signing context (except macOS/iOS which use certificates issued by Apple). The CAs just try to deliver the certificate in a format suitable for the developer environment. For example a JKS file for Java developers signing JAR files, a SPC file (i.e. a DER encoded PKCS#7 certificate) or a PKCS#12 file for Authenticode.

The code signing tools often accept various key and certificate formats:

  • signtool can use PKCS#12 keystores and PKV+SPC files for Authenticode signing
  • keytool can use PKCS#12 and JKS keystores for signing JAR files
  • Jsign can use PKCS#12 and JKS keystores, or PKV+SPC files for Authenticode signing (disclaimer: I'm the author)
  • osslsigncode PKCS#12 keystores or PKV+SPC files

Regardless of the format used, these tools will produce the same signature for a given file (except for the signing time and the timestamp of course).

Emmanuel Bourg
  • 9,601
  • 3
  • 48
  • 76