FULL PRODUCT VERSION :
JDK1.5.0-beta2-b51

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Java Web Start in JDK1.5.0-beta2 is unable to start an application that works perfectly well in Java 1.4.2.

The application in question uses the all-permisions JNLP tag and as such is signed. It seems that something about the signitues on the Jars is causing WebStart to break.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) open a link for a signed JWS application that requiers all-permissions
2) wait for application to download
3) Web Start will say "starting application..."

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application starts
ACTUAL -
watched it popup warning dialog saying "Failed to validate certificate. This application will not be run."

ERROR MESSAGES/STACK TRACES THAT OCCUR :
 "Failed to validate certificate. This application will not be run."

Exception was:
java.security.cert.CertificateException: Check leaf key usage failed in certificate
        at com.sun.deploy.security.CertUtils.checkUsageForCodeSigning (Unknown source)
        ...

there's no way to copy the exception from the exception dialog so i've had to type exception fragment in.

REPRODUCIBILITY :
This bug can be reproduced always.

Release Regression From : 1.4.2
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Incident Review ID: 275416) 
======================================================================

N/A

the exception is caused by the check in CertUtils.java, method checkLeafKeyUsageForCodeSigning, we do a check on 

  
		   if (extKeyUsageInfo.contains(OID_EKU_ANY_USAGE) == false && 
		       extKeyUsageInfo.contains(OID_EKU_CODE_SIGNING) == false)
		       {
			   Trace.msgSecurityPrintln("trustdecider.check.leafkeyusage.extkeyusageinfo");
			   return false;
		       }

It returned false here because the extKeyUsageInfo does not contains OID_EKU_ANY_USAGE and OID_EKU_CODE_SIGNING.  It only contains OID_EKU_SERVER_AUTH and OID_EKU_CLIENT_AUTH.  Therefore the exception is thrown.

We do not have such check in 1.4.2 java web start.


  xxxxx@xxxxx   2004-06-02

the problem is the application jar is signed with a server certificate.  it should be signed with a coding signing certificate instead.


  xxxxx@xxxxx   2004-06-02

I'm not clear on the distinction described here, but if it is in fact necessary, can we get a better error in the next release, something like: "This jar was signed with a server certification, not a 'code-signing' certification.  Please notify the provider/vendor."

This is really a great inconvenice to me.  I don

This is really a great inconvenice to me.  I don't want to use a code sigining certificate when I could've used a server certificate before to sign my applets. Now I have to purchase two separate certificates, a code signing certificate and a server certificate.  What is the reasoning for this.

You mean the Thawte Super Cert we just renewed for US$700+ cannot also be used for code signing???  UN-F-ING-BELIEVABLE.

I received the same error trying to deploy a signed applet. The applet was signed using a trial/test PKCS#7 code signing certificate from Thawte. It worked under 1.4.2.

This is ridiculous. We have a signed applet that is critical to our business, and now all of our customers are calling complaining because it no longer works. Auto-update is clobbering 1.4.2 every time. Thanks Sun - "this is not a bug" may be true, but it's a very bad way to treat the developer community. Whoever came up with this new feature should be fired.

Why is it ANY_USAGE && CODE_SIGNING (and condition)? Shouldn't it be an "or condition" (ANY_USAGE || CODE_SIGNING)?