United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8030813 : Signed applet fails to load when CRLs are stored in an LDAP directory

Details
Type:
Bug
Submit Date:
2013-12-19
Status:
Closed
Updated Date:
2014-04-18
Project Name:
JDK
Resolved Date:
2013-12-23
Component:
security-libs
OS:
Sub-Component:
java.security
CPU:
Priority:
P1
Resolution:
Fixed
Affected Versions:
7u25,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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
Initial assignment
                                     
2013-12-19
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.
                                     
2013-12-20
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.

                                     
2013-12-20
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
                                     
2013-12-20
Is there a webrev available for this fix ?
                                     
2013-12-20
Could you please revise the synopsis so that it describes the actual problem rather than a generic symptom?  Thanks.
                                     
2013-12-20
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.
                                     
2013-12-20
Changing to 8-critical-approved since Christophe has approved.
                                     
2013-12-23
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aef6c726810e
User:  mullan
Date:  2013-12-23 20:25:12 +0000

                                     
2013-12-23
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/aef6c726810e
User:  lana
Date:  2013-12-31 18:57:54 +0000

                                     
2013-12-31
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 
                                     
2014-02-06



Hardware and Software, Engineered to Work Together