JDK-4780497 : REGRESSION: 1.4.1_01 signed applets don't work anymore
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.4.1,1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2002-11-18
  • Updated: 2003-03-11
  • Resolved: 2003-02-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.4.1_03 03Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4814016 - extension installation broken in 1.4.1_01: ExtensionInstallationException thrown
Duplicate :  
JDK-4812909 - Problem to handle invalid web server certificate
Relates :  
JDK-4775420 - REGRESSION: Signed applet fails only on JRE 1.3.1_06
Description

Name: gm110360			Date: 11/18/2002


FULL PRODUCT VERSION :
JRE 1.4.1_01

FULL OPERATING SYSTEM VERSION :
Windows 2000 SP3

A DESCRIPTION OF THE PROBLEM :
My signed applet doesn't work with 1.4.1_01 anymore. This
was tested on IE 6.0. It worked before, nicely, with
1.3.1_0x and 1.4.1.

The certificate is a standard Verisign one.

The behaviour is this:
- launch applet
- the user is NOT prompted with the certificate/access
granting dialog, unlike before
- AccessControlException is thrown

In fact, the behaviour is as if the property "usePolicy"
had been defined, even though it hadn't.

Nothing had been changed in my applet and the only change
was using 1.4.1_01. Here is the link to the forum where
others have been experiencing the same thing:

http://forum.java.sun.com/thread.jsp?forum=63&thread=315281


REGRESSION.  Last worked in version 1.4.1

REPRODUCIBILITY :
This bug can be reproduced always.

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

(Review ID: 166689) 
======================================================================

Name: gm110360			Date: 11/18/2002


FULL PRODUCT VERSION :
JRE 1.4.1_01

FULL OPERATING SYSTEM VERSION :
Windows 2000 SP3

A DESCRIPTION OF THE PROBLEM :
My signed applet doesn't work with 1.4.1_01 anymore. This
was tested on IE 6.0. It worked before, nicely, with
1.3.1_0x and 1.4.1.

The certificate is a standard Verisign one.

The behaviour is this:
- launch applet
- the user is NOT prompted with the certificate/access
granting dialog, unlike before
- AccessControlException is thrown

In fact, the behaviour is as if the property "usePolicy"
had been defined, even though it hadn't.

Nothing had been changed in my applet and the only change
was using 1.4.1_01. Here is the link to the forum where
others have been experiencing the same thing:

http://forum.java.sun.com/thread.jsp?forum=63&thread=315281


REGRESSION.  Last worked in version 1.4.1

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 166689)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_03 mantis-beta tiger FIXED IN: 1.4.1_03 mantis-beta tiger INTEGRATED IN: 1.4.1_03 mantis-b16 mantis-beta tiger tiger-b03
14-06-2004
EVALUATION ###@###.### 2002-11-19 This is due to our new security check added into 1.4.1_01, which make some of the certificate not valid anymore but was accepted in JRE 1.4.1. In JRE 1.4.2, we will pop up a warning dialog box and tell the user the certificate is bad, but this fix hasn't been in 1.4.1 yet. So in JRE 1.4.1, the applet will just run untrusted. Please ask user to sign the applet using another certificate. Or send me the testcase so that I can tell why the certificate he was using is bad. Dennis Gu We should definitely ask for a testcase so we can see why this was failing for an allegedly standard verisign cert. We need to make sure there aren't any unexpected failures resulting from the new cert checks. ###@###.### 2002-11-21 ###@###.### 2003-01-14 Two jar file has been attached to this bug report, both of them failed to run under 1.4.1_01 with our new security check feature. The problem is that the jar file is signed by Verisign Class 3 root CA certificate, which is a latest CA come from Verisign (Validate time from 1996-2028), in our root ca cert file (cacerts), we do have this root ca but the validate time is (1996-2004), therefore we think this root ca is not in our cacerts and failed on CheckBasicConstraint check. We definitely need to solve this issue in Mantis, plus backport to previous JRE updated release, such as 1.4.1_0x and 1.3.1_0x. Dennis Gu ###@###.### 2003-01-27 A new method canonicalize() has been added into TrustDecider.java, which will replace the root CA cert in certificate chain using our trusted root CA in cacerts file.
27-01-2003