Are Java code signing certificates the same as SSL certificates?

Question

I'm looking for code signing signatures for Java, so my Java applets do not trigger such scary security warnings. However, all the places that I found offer them to charge (in my opinion) too much, for example, more than 200 US dollars per year. When doing research, the code signing certificate seems almost the same as the SSL certificate.

The main question I have is: can I buy an SSL certificate, but use it to sign Java applets?

Answer 1

Short answer: No, they are different.

Long answer: this is the same certificate, and it uses the same cryptography software, but there are flags in the certificate indicating what it can be used for. Code signing and web server are different.

Answer 2

When I import a new CA certificate into Firefox (etc.), I can choose which certificate uses it, I trust:

• Sign servers
• Sign code (e.g. your applet)
• Sign mail certificates

So, for me, the answer is: Yes, they are the same. Also, why not create your own OpenSSL (man openssl, man x509, man req, etc. on Unix)? Do you want to simply reassure the warnings, or do you want other people you have never met to trust your code? If you don’t need other users to attach trust to CA binding bundled with your browser, OS, etc. Use OpenSSL to generate your own.

And ask: "How to use OpenSSL to create your own certificates?" if the last is your choice.

Answer 3

Thawte offers code signing certificates here . I believe other certification services also offer this service. You can also create self-signed certificates, Java keytool .

Answer 4

X.509 certificates can include key usage fields (KU) and advanced key usage fields (EKU). An Oracle technical note describing how to create your RIA badge creates a certificate without any key usage flags, which works just fine (if you can get a trusted CA to sign it)

But more and more CAs issue certificates with these key usage fields. If present, these fields restrict the use of the certificate. The java plugin checks for these fields in EndEntityChecker :

/** * Check whether this certificate can be used for code signing. * @throws CertificateException if not. */ private void checkCodeSigning(X509Certificate cert) throws CertificateException { Set<String> exts = getCriticalExtensions(cert); if (checkKeyUsage(cert, KU_SIGNATURE) == false) { throw new ValidatorException ("KeyUsage does not allow digital signatures", ValidatorException.T_EE_EXTENSIONS, cert); } if (checkEKU(cert, exts, OID_EKU_CODE_SIGNING) == false) { throw new ValidatorException ("Extended key usage does not permit use for code signing", ValidatorException.T_EE_EXTENSIONS, cert); } if (!SimpleValidator.getNetscapeCertTypeBit(cert, NSCT_SSL_CLIENT)) { throw new ValidatorException ("Netscape cert type does not permit use for SSL client", ValidatorException.T_EE_EXTENSIONS, cert); } // do not check Netscape cert type for JCE code signing checks // (some certs were issued with incorrect extensions) if (variant.equals(Validator.VAR_JCE_SIGNING) == false) { if (!SimpleValidator.getNetscapeCertTypeBit(cert, NSCT_CODE_SIGNING)) { throw new ValidatorException ("Netscape cert type does not permit use for code signing", ValidatorException.T_EE_EXTENSIONS, cert); } exts.remove(SimpleValidator.OID_NETSCAPE_CERT_TYPE); } // remove extensions we checked exts.remove(SimpleValidator.OID_KEY_USAGE); exts.remove(SimpleValidator.OID_EXTENDED_KEY_USAGE); checkRemainingExtensions(exts); } 

Verification methods are as follows:

 /** * Utility method checking if the extended key usage extension in * certificate cert allows use for expectedEKU. */ private boolean checkEKU(X509Certificate cert, Set<String> exts, String expectedEKU) throws CertificateException { List<String> eku = cert.getExtendedKeyUsage(); if (eku == null) { return true; } return eku.contains(expectedEKU) || eku.contains(OID_EKU_ANY_USAGE); } 

So, if KU or EKU is not specified, checking KU or EKU will happily return true.

But

• If KU is specified, the KU digital signature must be one of them.
• if any EKUs are specified, either the signing of the EKU code (identified by oid 1.3.6.1.5.5.7.3.3) or any use of the EKU (identified by oid 2.5.29.37.0) must also be indicated.

Finally, the checkRemainingExtensions method checks the remaining critical EKUs. The only other critical ECU allowed to attend is

• main restrictions (oid "2.5.29.19") and
• subject alt name (oid 2.5.29.17)

If it finds any other critical ECU, it returns false.