sun.security.provider.certpath.DistributionPointFetcher

David Pomeroy dfpomeroy at gmail.com
Tue Jun 28 17:01:58 UTC 2011


Hi Sean,

I am using Open JDK 6.  Are the indirect CRL bugs in JDK 6 documented
anywhere?  Are there any workarounds?

I am setting enableCRLDP.

Thanks, Dave

On Tue, Jun 28, 2011 at 5:46 AM, Sean Mullan <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>  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); } }
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20110628/e5e80e2d/attachment.htm>


More information about the security-dev mailing list