<div dir="ltr"><div><div>Sorry, I hadn't noticed there were already a few bug entries on this topic [2].<br><br></div>Perhaps one way to guarantee uniqueness of the alias would be to use the certificate's thumbprint. This would also be consistent with the way certificates are identified in some Windows native tools (such as "netsh http add sslcert" [3]). It's less human friendly, but it would certainly prevent this type of problems. (This wouldn't necessarily solve the problem of certificates added to the store with an alias given by the user.)<br>
<br></div><div>Best wishes,<br><br></div><div>Bruno.<br></div><div><br>[2]: <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6483657">http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6483657</a><br>[3]: <a href="http://msdn.microsoft.com/en-us/library/ms733791%28v=vs.110%29.aspx">http://msdn.microsoft.com/en-us/library/ms733791%28v=vs.110%29.aspx</a><br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 10:03 PM, Bruno Harbulot wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div></div><div>Hello,<br><br></div><div>It seems there may be a bug in the Windows-ROOT store implementation [1], which prevents a number of certificates from being used.<br><br></div>
<div>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.<br>

<br></div><div>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).<br>

</div><div><br></div><div>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).<br>

<br></div><div>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.<br>

<br></div><div>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).<br>

<br></div><div>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.<br><br></div><div>Best wishes,<br><br>Bruno.<br>
</div><div><br><br>[1]: <a href="http://www.oracle.com/technetwork/articles/javase/security-137537.html" target="_blank">http://www.oracle.com/technetwork/articles/javase/security-137537.html</a><br></div></div>
</blockquote></div><br></div></div>