If you're comparing code signing certificates vs ssl certificates, here's the basic difference: SSL Certificates are for websites to enable HTTPS urls. Code Signing is for applying a digital signature to software and code to avoid security warnings when installing it.
A Java code signing certificate is useful for securing all types of Java software and executables. It gives assurance to users that the identity of the software publisher has been rigorously vetted by a publicly trusted certificate authority (CA).
Simply put, the Secured Socket Layer (SSL) enables a secured connection between two parties, usually clients and servers. SSL provisions a secure channel between two devices operating over a network connection. One usual example for SSL is to enable secure communications between web browsers and web servers.
Code Signing Certificates are used by software developers to digitally sign applications, drivers, executables and software programs as a way for end-users to verify that the code they receive has not been altered or compromised by a third party.
Short answer: No, they're different.
Long answer: It's the same sort of certificate and it uses the same crypto software, but the certificate has flags indicating what it is allowed to be used for. Code signing and web server are different uses.
When I import a new CA certificate in Firefox (etc.) I have the option of choosing which certificate uses I trust:
So to me the answer is: Yes, they're the same. Furthermore, why not generate your own with OpenSSL (man openssl, man x509, man req, etc. on Unix)? Do you want to just quiet down the warnings or do you want other people whom you've never met to trust your code? If you don't need other users to chain trust to the anchor CA's bundled with their browser, OS, etc., then use OpenSSL to generate your own.
And ask "How do I use OpenSSL to generate my own certificates?" if the latter is your choice.
Thawte offers code signing certificates here. I imagine other Certificate Authorities offer this service as well. You can also create self-signed certificates, with Java keytool.
X.509 certificates may include key usage fields (KU's) and extended key usage fields (EKU's). The Oracle tech note describing how to create sign your RIA's 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, CA's issue certificates with these key usage fields. When present, these fields restrict the usage of the certificate. The java plugin checks for the presence of these fields in the 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);
}
The check methods look 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 no KU or EKU is specified, the KU or EKU checker happily returns true.
But
Finally, the checkRemainingExtensions
method checks the remaining critical EKU's. The only other critical EKU's allowed to be present are
If it finds any other critical EKU, it returns false.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With