sun.security.provider.certpath.DistributionPointFetcher

[Sean Mullan]

On 6/28/11 1:01 PM, David Pomeroy wrote:
> Hi Sean,
>
> I am using Open JDK 6.  Are the indirect CRL bugs in JDK 6 documented anywhere?
> Are there any workarounds?

See:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6509162
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6542169

No known workarounds. It would help if you tested with JDK 7 [1] so we could 
verify if the problem has fixed.

If it still fails with JDK 7, please file a bug (and attach a test program) at 
http://bugs.sun.com

Thanks,
Sean

[1] http://jdk7.java.net/download.html

>
> I am setting enableCRLDP.
>
> Thanks, Dave
>
> On Tue, Jun 28, 2011 at 5:46 AM, Sean Mullan <sean.mullan at oracle.com
> <mailto:sean.mullan at oracle.com>> wrote:
>
>     Are you using JDK 7? There were some bugs fixed with indirect CRLs in JDK 7.
>
>     Also, make sure you set the system property com.sun.security.enableCRLDP to the
>     value true when running, ex: java -Dcom.sun.security.__enableCRLDP=true ...
>
>     --Sean
>
>
>     On 6/28/11 1:05 AM, Xuelei.Fan at Oracle.Com wrote:
>
>         Can you provide the code to reproduce the exception? Or is it possible
>         attach
>         the CertPath building debugger log?
>
>         Xuelei
>
>         On Jun 28, 2011, at 11:59 AM, David Pomeroy<dfpomeroy at gmail.com
>         <mailto:dfpomeroy at gmail.com>>  wrote:
>
>             Hello All,
>
>             I am trying to get a servlet to download and check a CRL.  The CRLDP
>             is in
>             the client's certificate and the CRL is marked "indirect CRL" so that it
>             can be signed by a different key than the client cert issuer.  The
>             following block of code is invoked but the DistributionPointFetcher
>             can't
>             seem to build a valid path and a CRLException is thrown.  My
>             assumption was
>             this would work if I included the CRL signing certificate in my
>             truststore.
>             What I find odd while stepping through this in a debugger is that the
>             "certStores" object contains only the client certificate which is to be
>             validated, so it makes sense that X509CertSelector doesn't find the
>             right
>             cert in there.
>
>             Has anyone got indirect CRLs validated before?  I'd be interested in the
>             details of a test setup that works.  I can provide more details of
>             my test
>             setup if necessary.
>
>             Thanks, David
>
>
>             // Obtain and validate the certification path for the complete // CRL
>             issuer (if indirect CRL). If a key usage extension is present // in
>             the CRL
>             issuer's certificate, verify that the cRLSign bit is set. if
>             (indirectCRL)
>             { X509CertSelector certSel = new X509CertSelector();
>             certSel.setSubject(crlIssuer.__asX500Principal()); boolean[] crlSign =
>             {false,false,false,false,__false,false,true};
>             certSel.setKeyUsage(crlSign);
>             PKIXBuilderParameters params = null; try { params = new
>             PKIXBuilderParameters (Collections.singleton(anchor)__, certSel); }
>             catch
>             (__InvalidAlgorithmParameterExcep__tion iape) { throw new
>             CRLException(iape);
>             } params.setCertStores(__certStores);
>             params.setSigProvider(__provider); try {
>             CertPathBuilder builder = CertPathBuilder.getInstance("__PKIX");
>             PKIXCertPathBuilderResult result = (PKIXCertPathBuilderResult)
>             builder.build(params); prevKey = result.getPublicKey(); } catch
>             (Exception
>             e) { throw new CRLException(e); } }
>
>