Windows-ROOT keystore merging aliases (and hiding certificates)

[Bruno Harbulot]

Hello,

It seems there may be a bug in the Windows-ROOT store implementation [1],
which prevents a number of certificates from being used.

For example, a Windows 7 machine with the default certificates list should
have the "UTN-USERFirst-Hardware" CA certificate. However, when listing the
contents of the "Windows-ROOT" keystore, it cannot be found.

I haven't looked into the source code for this implementation, but I think
this is due to the fact that the certificate's "Friendly Name" (in Windows
terminology) is used as the alias name in the keystore. Unfortunately, this
friendly name is not unique, so some certificates would be overwritten in
the map implemented in the keystore (or a similar data structure, I
presume).

Indeed, the certificate with "CN = UTN-USERFirst-Object" and the one with
"CN = UTN-USERFirst-Hardware" both use the "USERTrust" friendly name (so do
other UTN certificates).

If you change the friendly name manually to something different, it is then
visible via the keystore. To try this, run mmc.exe, add the "Certificates"
snap-in for the current user, open "UTN-USERFirst-Hardware" in the "Trusted
Root Certification Authorities" list, and edit its "Friendly Name" in the
details panel.

By listing all the aliases in the Windows-ROOT keystore, looking for
duplicate names and comparing with the number in the Windows list, it
appears there are about 60 certificates hidden this way and unusable (22
aliases that have multiple certificates).

Perhaps a way to fix this bug would be to add a number to the alias name if
the friendly name has already been seen, when loading the Windows store.

Best wishes,

Bruno.


[1]: http://www.oracle.com/technetwork/articles/javase/security-137537.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140202/c490aa76/attachment.htm>