Filed https://bugs.openjdk.org/browse/JDK-8395755. Worth investigating.
Thanks, Weijun > On Oct 23, 2026, at 16:30, Dimitris Soumis <[email protected]> wrote: > > Hi, > > I've been investigating an issue with the SunMSCAPI provider where multiple > certificates in the Windows-MY keystore share the same Windows friendly name. > > Currently, CKeyStore.storeWithUniqueAlias() handles these collisions by > appending numeric suffixes, producing aliases such as server, server (1), > server (2), etc. This works correctly for ensuring uniqueness, but it also > means that applications cannot reliably determine which entries originally > shared the same Windows name. > > For example, consider two certificates with the original name server and an > unrelated certificate whose actual name is server (1). Depending on the > enumeration order, the generated Java aliases can overlap with names that > were explicitly assigned in Windows. Comparing the certificate subjects or > stripping the numeric suffixes would not reliably distinguish them. > > I've reproduced the duplicate-alias behavior on Windows with two certificates > sharing the same friendly name but having different EKUs. Looking at the > implementation, the original alias is already preserved in > CKeyStore.KeyEntry.alias, while the entries map uses the disambiguated > aliases as keys. However, this information is not exposed through the public > KeyStore API. > > Would it make sense to expose the pre-disambiguation alias as a > provider-specific entry attribute through > KeyStoreSpi.engineGetAttributes(String)? > > The implementation should be relatively small, since the information is > already available. It would not require changes to the existing alias > generation, certificate selection, or native Windows code. Applications could > then retrieve the original alias using KeyStore.getAttributes() without > depending on internal JDK implementation details. > > I noticed the related work in JDK-6483657, JDK-8185844 and JDK-8187634, which > addresses alias uniqueness and consistency. Unless I've missed something, the > original alias still isn't accessible to applications. > > One consideration is Java 17 compatibility, since KeyStore.getAttributes() > was introduced in Java 18. I wonder whether exposing the same attribute > through KeyStore.getEntry() would also be appropriate, or whether this should > be handled separately. > > Does this sound like a reasonable enhancement to SunMSCAPI? > > Regards, > Dimitris
