sun.security.provider.certpath.DistributionPointFetcher

[Xuelei.Fan at Oracle.Com]

On Jun 29, 2011, at 4:51 AM, David Pomeroy <dfpomeroy at gmail.com> wrote:

> Hi Sean,
> 
> openjdk7 complained that my Crl Server certificate did not contain a Subject Key Identifier. 
It's a must-to-have field to comply with RFC 5280.

> Once I added this, validating the indirect CRL issuer worked as expected.
> 
Glad to know it works in JDK 7.

> When I switched back to openjdk6, the CRL validation still fails.  I have attached the certpath debug from each jvm.  If you look at the line "certpath: SunCertPathBuilder.engineBuild([", jdk6 only adds my Sub CA certificate as a trusted source, where jdk7 adds all 3 certs from the truststore, including the Crl Issuer's certificate.  Perhaps jdk6 is looking for specific criteria in the trusted certificates for use in validating the CRL?  
> 
> When I switched back to sun jdk 6, I got a different error.  It's as if it is not even trying to build a verification path at all.  I attached that debug as well.
> 
> Thanks for jdk7 suggestion, I definitely learned something.  However, I'd really like to get this working on a version 6 jvm.  Any workaround suggestions from you or the group would be greatly appreciated.  
No known workaround. You may be able to disable certificate status checking in the default provider, and check the certificate status by a customized PKIXCertPathChecker.

Xuelei

> 
> Thanks, Dave
> 
> 
> On Tue, Jun 28, 2011 at 11:14 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 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); } }
> 
> 
> 
> <openjdk6-fails.txt>
> <openjdk7-succeeds.txt>
> <sunjdk6-fails.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20110629/73af57b5/attachment.htm>