JDK-8025708 : Certificate Path Building problem with AKI serial number
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7u17
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • Submitted: 2013-03-27
  • Updated: 2016-06-22
  • Resolved: 2014-02-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u121Fixed 8u20Fixed 9 b04Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version  " 1.7.0_17 " 
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) Client VM (build 23.7-b01, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
If an end entity certificate has an AKI extension with a key identifier and serial number and the issuing (subordinate, untrusted) certificate does not have a serial number in its AKI extension, just the key identifier, then the default cert path builder cannot build a path to the trusted root certificate.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a 3 tier PKI Hierarchy (Root, Subordinate, EndEntity). Give the EndEntity certificates a AKI extension with a key identifier and the Serial number of the Subordinate. Give the subordinate an AKI extension with a key identifier but do not include the serial number (of the root) in it. Place the Root in a KeyStore (therefore trusted). Place the Subordinate in a cert store. Try and build a certfication path for the EndEntity using CertPathBuilder (with default provider type).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A certification Path should be built.
ACTUAL -
 It will fail. Enabling debugging seems to indicate that the reason that the path is not built is that the serial number on the subordinate does not match what is expected.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Failure case:

certpath: ForwardBuilder.getMatchingCerts()...
certpath: ForwardBuilder.getMatchingCACerts()...
certpath: X509CertSelector.match(SN: 1
  Issuer: CN=Test  Root Certification Authority,  O=GOV, C=AU
  Subject: CN=Test Root Certification Authority, O=GOV, C=AU)
certpath: X509CertSelector.match: serial numbers don't match

Using an End Entity cert that does not have the serial number is its AKI:
certpath: SunCertPathBuilder.depthFirstSearchForward(CN=Test Root Certification Authority,  O=GOV, C=AU, State [
  issuerDN of last cert: CN=Test  Root Certification Authority,  O=GOV, C=AU
  traversedCACerts: 1
  init: false
  keyParamsNeeded: false
  subjectNamesTraversed:

certpath: ForwardBuilder.getMatchingCerts()...
certpath: ForwardBuilder.getMatchingCACerts()...
certpath: X509CertSelector.match(SN: 1
  Issuer: CN=Test Root Certification Authority, O=GOV, C=AU
  Subject: CN=Test  Root Certification Authority, O=GOV, C=AU)
certpath: X509CertSelector.match returning: true

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
If the subordinate is put into the keystore (i.e. trusted) then the problem does not occur
Comments
If we decide to fix in JDK 7u, pay attention to the reported regression : JDK-8156792
22-06-2016

The affected test cases could pass in nightly result: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=669066.CORELIBS-JDK-NIGHTLY-JTREG-14 Verified it.
26-12-2014

This looks like a similar problem as JDK-8010112. In that bug, I made a change where the AKIDs were not being matched correctly for CRLs. This looks like a similar change should be made when building certpaths. Here's the relevant comment from 8010112: DistributionPointFetcher.verifyCRL was not comparing Authority Key Ids correctly. It was comparing the bytes of the entire extension value, instead of just the KeyIdentifier field. It turns out that there are some AKID extensions that have matching key ids but also may include additional information in the other fields, causing the previous comparison to fail even though the key identifiers match.
01-10-2013