JDK-8030813 : Signed applet fails to load when CRLs are stored in an LDAP directory
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7u25,8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-12-19
  • Updated: 2014-04-18
  • Resolved: 2013-12-23
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 JDK 7 JDK 8 JDK 9
1.4-poolResolved 7u51Fixed 8 b122Fixed 9Fixed
Related Reports
Relates :  
JDK-8030828 - [ Deploy Peer of JDK-8030813 ] Signed applet fails to load when CRLs are stored in an LDAP directory
Description
         
SHORT SUMMARY: Revocation checking via LDAP URLs ends in CNFE
DESCRIPTION:

As implemented from 7u25, revocation checks of CRLs using LDAP URLs from certificates of signed applets results in recursive calls to revocation checking and a resultant java.lang.ClassNotFoundException.

This problem existed prior to 7u25, but we are getting several reports of it now because revocation was enabled by default starting in 7u25 for signed applets and JNLP applications.
Comments
There is no regression tests available for this bug. Marking this as verified based on the status of SQE Tests for CRL developed for JEP 124 using JDK 8 build 1.8.0 b128
06-02-2014
Changing to 8-critical-approved since Christophe has approved.
23-12-2013
SQE approves this critical request. This is a customer reported issue. There will be no regression test for this fix. We have SQE coverage on the library side for CRL from LDAP (JEP124). This is an issue affecting only Deploy. The Deploy team is working on a test plan to address this gap.
20-12-2013
Could you please revise the synopsis so that it describes the actual problem rather than a generic symptom? Thanks.
20-12-2013
Is there a webrev available for this fix ?
20-12-2013
Release team: Can you please run this by Christophe Ravel so QA are on-board? If he's OK then this is approved and you can change this to 8-critical-approved
20-12-2013
8-critical-request justification: This bug fix is needed because it is a serious issue affecting several users/customers and there are several outstanding escalations open. Workarounds: turn off revocation checking (not recommended) or re-issue/use a certificate without LDAP information. Neither of these are good workarounds. Projected schedule for integration: fix will be pushed by 12/23 or 12/24 if approved Risk / impact: The fix has been reviewed internally by Vincent Ryan and Andy Herrick. I will be doing a JPRT run later today. The fix is also going to be tested by a few of the impacted customers to make sure it corrects the problem. Size/Scope of fix: 3 files changed, about 30 lines of new code. Fix spans both JDK and deploy code (see 8030828) Testing coverage: JPRT run, and testing by customers with fix. Because it requires LDAP, it is hard to write a regression test, so I will be working with SQE to make sure all of the existing tests using LDAP are run, and more are added for this specific bug.
20-12-2013
Bug evaluation: The problem occurs with applets or JNLP apps signed with certificates that contain a CRL Distribution Points Extension with an LDAP URL. The JDK CertPath code instantiates an LDAP CertStore in order to download these CRLs. The "Sun" provider implementation of the LDAP CertStore uses JNDI to retrieve the CRLs from an LDAP directory. As part of establishing an InitialContext, JNDI looks for application resource files named "jndi.properties" on the ClassPath, and if found, uses the values of the properties in establishing the context (see the javax.naming.InitialContext API for more information). However, the jndi.properties files cannot be loaded (even if they don't exist) until the signed JARs on the classpath have been verified, which triggers a recursive call to download the CRLs, and so forth. Eventually this results in a ClassNotFoundException error. The fix is to introduce a new system property (for internal JDK use only), that is set by the deployment code when checking revocation, and which disables the JNDI application resource file lookup when downloading CRLs.
20-12-2013
Initial assignment
19-12-2013