java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03) Java HotSpot(TM) Client VM
(build 1.4.2_02-b03, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows XP SP1
EXTRA RELEVANT SYSTEM CONFIGURATION :
Require 3rd Party JCE provider impementation. Can supply one if required.
A DESCRIPTION OF THE PROBLEM :
Problem: Java Webstart does not trust the sun jce code signing ca certificate used to sign 3rd party jce
provider impelmentations and there is no way to work around this.
CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto,
ST=CA, C=US
I accept that this certificate is not for use in general for object signing however the JCE in 1.4.2
requires that the 3rd party provider be signed a certificate issued off this CA.
In the case of the java plugin it is possible to double sign the provider jar with a object signing
certificate issued by a trusted root ca. Webstart does not permit a 2nd signature on the provider jar
file.
Using the file "as is" results in the security warning
"Failed to verify the authenticity of this certificate. No assertions can be made about the origin or
validity of the code.
It is highly recommended not to install and run this code"
Which is not something that customers of our provider what their end users to see.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
using the JNLP extension mechanism to include a seperate jnlp file e.g.
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.4+"/>
<jar href="testApp.jar"/>
<extension name="KeyToolsProJava" href="KeyToolsPro.jnlp"/>
</resources>
the appropriate section of the KeyToolsPro.jnlp looks like:
<security>
<all-permissions/>
</security>
<resources>
<jar href="KeyToolsPro_jce1-2-1_signed.jar"/>
</resources>
KeyToolsPro_jce1-2-1_signed.jar is a JCE provider implementation and is signed by
CN=Betrusted, OU=Java Software Code Signing, O=Sun Microsystems Inc.
CertReq number: <347>
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
To get a similar dialog to the default "X was signed by a cert issued by a known CA continue if you
feel thats ok"
ACTUAL -
Security warning dialog:
Do you want to install and run: KeyTools Pro Java Signed and distributed by: Betrusted
"Failed to verify the authenticity of this certificate. No assertions can be made about the origin or
validity of the code.
It is highly recommended not to install and run this code"
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Like other JCE providers it looks like we have to provider our own JCE framework implementation and
bypass the Sun one.
Essentially this means duplicating the javax.crypto and java.security packages in a seperate namespace
making code 100% incompatible with your JCE.
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03) Java HotSpot(TM) Client VM
(build 1.4.2_02-b03, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows XP SP1
EXTRA RELEVANT SYSTEM CONFIGURATION :
Require 3rd Party JCE provider impementation. Can supply one if required.
A DESCRIPTION OF THE PROBLEM :
Problem: Java Webstart does not trust the sun jce code signing ca certificate used to sign 3rd party jce
provider impelmentations and there is no way to work around this.
CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto,
ST=CA, C=US
I accept that this certificate is not for use in general for object signing however the JCE in 1.4.2
requires that the 3rd party provider be signed a certificate issued off this CA.
In the case of the java plugin it is possible to double sign the provider jar with a object signing
certificate issued by a trusted root ca. Webstart does not permit a 2nd signature on the provider jar
file.
Using the file "as is" results in the security warning
"Failed to verify the authenticity of this certificate. No assertions can be made about the origin or
validity of the code.
It is highly recommended not to install and run this code"
Which is not something that customers of our provider what their end users to see.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
using the JNLP extension mechanism to include a seperate jnlp file e.g.
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.4+"/>
<jar href="testApp.jar"/>
<extension name="KeyToolsProJava" href="KeyToolsPro.jnlp"/>
</resources>
the appropriate section of the KeyToolsPro.jnlp looks like:
<security>
<all-permissions/>
</security>
<resources>
<jar href="KeyToolsPro_jce1-2-1_signed.jar"/>
</resources>
KeyToolsPro_jce1-2-1_signed.jar is a JCE provider implementation and is signed by
CN=Betrusted, OU=Java Software Code Signing, O=Sun Microsystems Inc.
CertReq number: <347>
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
To get a similar dialog to the default "X was signed by a cert issued by a known CA continue if you
feel thats ok"
ACTUAL -
Security warning dialog:
Do you want to install and run: KeyTools Pro Java Signed and distributed by: Betrusted
"Failed to verify the authenticity of this certificate. No assertions can be made about the origin or
validity of the code.
It is highly recommended not to install and run this code"
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Like other JCE providers it looks like we have to provider our own JCE framework implementation and
bypass the Sun one.
Essentially this means duplicating the javax.crypto and java.security packages in a seperate namespace
making code 100% incompatible with your JCE.
- duplicates
-
JDK-4928787 Java Web Start should not reject multiply signed jars.
- Resolved