FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.14393]
The codepath is such that this affects other OSes, as well.

A DESCRIPTION OF THE PROBLEM :
I've created a Certificate which contain two CRLDistributionPoint in the CRLDistributionPoints field. These are two separate HTTP web servers, which provide the same CRL.

I see the following happen when I use the PKIX CertPathValidator:
If the first listed endpoint is unavailable (causing an IOException either by blocking the port in the firewall or shutting down the software), then revocation checking will fail even though the CRL is available on the next CRL DistributionPoint.

From what I can determine, the cause is that the for-loop in: http://hg.openjdk.java.net/jdk/jdk/file/71c04702a3d5/src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java#l134
will exit early with an exception and never check the second CRL DistributionPoint.

The result of the failure is stored in the CRL cache. If the underlying URICertStore is called within the CRL Check Interval, then the same method (which otherwise throws the exception) will return an empty collection instead and the second DistributionPoint is checked as expected.

This was observed in JRE 8u144 but the same for-loop is present in the latest JDK.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a certificate with multiple HTTP Endpoints stored in different DistributionPoint fields
2. Make the CRL available on the second HTTP Endpoint and ensure that the first endpoint is unavailable.
3. Setup the PKIX CerthPathValidator
4. Validate the created Certificate against the PKIX CertPathValidator
5. Validate the created Certificate a second time (within 30 second) against the PKIX CertPathValidator.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Both validation checks should succeed.
ACTUAL -
The first validation check fails with an "Unable to determine revocation status due to network error".

The second validation check fetches the CRL from the second distribution point and succeeds the revocation checking.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Only specify one CRL DistributionPoint in certificates.