FULL PRODUCT VERSION :
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Version 6.1.7601

EXTRA RELEVANT SYSTEM CONFIGURATION :
-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT

A DESCRIPTION OF THE PROBLEM :
I would like to be able to use the SunMSCAPIProvider as described on your website http://java.sun.com/developer/technicalArticles/J2SE/security/: "a consistent behavior that matches what native applications have when they use the same native library"

So if a certificate for SSL connection is trusted in Windows (e.g. in Internet Explorer) my Java application started with the options
-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT
should trust the same certificate. However due to or similarly to bug 6483657 it seems that not all certificates are included because they have either the same alias or no alias (Friendly Name in MS terms) and the same CN in the Subject.

Due to the implementation of sun.security.validator.KeyStores.getTrustedCerts(KeyStore ks) which assumes that all aliases are unique only one of the certificates will be included (the first to be returned by alias).

Maybe Java lacks a clear definition of the purpose of an alias in the sense that it may or may not be assumed to be a Unique Identifier as in the case of JKS, which would help to decern what part of Java to blame.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
use -Djavax.net.debug=ssl shows which certificates are added where duplicate aliases will be missing


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Open MMC, add Certificates plugin, go to Trusted Root Certification Authorities, Certificates, Order by Friendly Name, make sure they all have a filled in unique value.