I have a certificate which is signed by COMODO RSA Domain Validation Secure Server CA (md5: 83 E1 04 65 B7 22 EF 33 FF 0B 6F 53 5E 8D 99 6B, sha1: 33 9C DD 57 CF D5 B1 41 16 9B 61 5F F3 14 28 78 2D 1D A6 39). I’m using this certificate in my web server, which is being trusted by majority of browsers. I also use this certificate to sign Java Applet. When I deploy applet to production, end users see error that application can not be trusted. They can get away with importing my certificate to their truststore using KeyStore Explorer - Download, but I don’t want to make users perform manual actions, I just want my certificate to be trusted by Java platform by default. So what I’m going to do is create new certificate and ask Comodo to sign my certificate with different intermediate certificate - basically with any other certificate which can be found in standard JDK or JRE installation at
Your website’s certificate might not be properly installed if Java is complaining about it during the connection. Recent versions of Java have included ‘cacerts’ the Comodo RSA Certification Authority as a CA but older versions, going back to ~ 1.5.1 r08 would have the ‘AddTrust External CA Root’ as a trusted CA. If the appropriate chain, up to the AddTrust, is not present during the SSL/TLS session, connections may not be seamless.
I have not personally tried it but know Java can be temperamental, it is like going to want you to have a certificate with ‘Code Signing’ as an EKU and or a cert with the Netscape Cert Type attribute of ‘Object Signing’. The certificate you have is only valid Client/Server communications as it’s missing the necessary bits for Code/Object signing.(even though part of it is there as it does have a 'digitalSignature attribute)
Sorry for the delayed response. After a little bit investigation, I found out that I had configured certificate chain incorrectly. I followed instructions noted here http://java.thedizzyheights.com/2011/09/installing-ssl-certificate-chains-in-jetty-and-possibly-other-java-installations/ and my first problem which I did not describe here and I managed to implement hacky workaround is fixed. However as for the signing, you are right, extended key usage of my certificate is limited to serverAuth and clientAuth, so Java platform gives different error: Extended key usage does not permit use for code signing while trying to run applet. This means that (as you already noted) I need another certificate with “code signing” option.