JDK-8161128 : Release Note: MSCAPI KeyStore can handle same named certificates
  • Type: Sub-task
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 7u121,8u92,8u101,9
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2016-07-11
  • Updated: 2022-06-14
  • Resolved: 2016-12-08
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
7u121Resolved 8u101Resolved 9Resolved
Description
Java SE KeyStore does not allow certificates that have the same aliases.
http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html

However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names.

The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.

Please note, this fix does not enable creating same-named certificates with the Java API. It only allows you to deal with same-named certificates that were added to the keystore by 3rd party tools.

It is still recommended that your design not use multiple certificates with the same name.  In particular, the following sentence will not be removed from the Java documentation:
 "In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case."
http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
Comments
7u131 is not in work yet. 8u101 is delivered.
30-08-2016
The bug fix was just backported to jdk7u. The fix is scheduled for 7u131, so this is added to "Affects Versions".
15-07-2016
Yes, everything is as you've said, so I'm setting the "Affects Versions" to 8u101 and 8u102.
13-07-2016
This "Affects Version/s" just applies to the release notes subtask to identify the version and update number of the Release Notes that this issue is incorporated in. As I understand the parent task, the label for JDK-6483657 says PSU16_03 and the backport to 8u102 is marked as fixed so that would be in Affected Version, There is also a backport for 8u101 that was listed as fixed so 8u101 might need to be added as well. The backports in JDK-6483657 for 6 and 7 are marked as "won't fix" and as "unresolved" so you wouldn't want 6u121 and 7u111 listed in the Release Notes subtask. If that understanding is correct, then you would add 8u101 and 8u102 to the Affects Version/s field and I'll incorporate the issue in the Release Notes for those two updates.
13-07-2016
[~cwayne] it was the behavior "by design" from the very beginning. Would it be appropriate to set the Affected Versions to 6, 7, 8, 9?
12-07-2016
What is the Affects Version for this one?
12-07-2016