Windows 7 and Windows 2008 Certificates snap-in shows an incomplete list of root certificates installed. As you work on the computer (navigating to a website with ssl, for example) this list expands (ie, Windows shows more certificates, but they were already installed on your system). Is it possible to change this behavior? Is there any way to tell Windows to always display all certificates installed? The problem is that the list of certificates appears in many places (to configure PEAP authentication, for example) and if it is incomplete, the user tends to think that root certificate is not installed.

Hi, In order to clarify the issue more clearly, please capture the screenshots for the Certificates snap-in which you stated that shows incomplete list of root certificates installed and the example which shows more certificates. How to capture a screenshot ====================== 1. Please press the Print Screen key (PrtScn) on your keyboard. 2. Click the "Start" Button, type "mspaint" in the Search Bar and Press Enter. 3. In the Paint program, click the "Edit" menu, click "Paste". Then click the "File" menu, and click "Save". 4. The "Save As" dialogue box will appear. Type a file name in the "File name:" box, for example: "screenshot". 5. Make sure "JPEG (*.JPG;*.JPEG;*.JPE;*.JFIF)" is selected in the "Save as type" box, click "Desktop" on the left pane and then click "Save". You can refer to the following link to upload the information: http://social.technet.microsoft.com/Forums/en-US/w7itproui/thread/4fc10639-02db-4665-993a-08d865088d65 Thank you for your understanding and support. Regards, Sabrina TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.com This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

OK. After a clean installation of Windows 7 (applying all the updates) the Certificates snap-in shows this list of root certificates: If you try to configure the PEAP authentication of a network connection the list showed is: As you can see StartCom, for example, does not appear in these listings (although the root certificate is installed on Windows). Now, if you browse to https://www.startcom.org/ (evidently the browser doesn't complain about the certificate) and try again the previous steps, magically the root certificate of StartCom is available on all the GUI tools: And there is a long list of installed root certificates that apparently are missing on Windows 7.

A brief understanding can be found here: http://technet.microsoft.com/en-us/library/cc751157.aspx How Root Certificate Distribution Works Root certificates are updated on Windows Vista automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes. Root certificates are also delivered for Windows XP and earlier via the Microsoft Update Catalog. Visitors to the Catalog can search on “root update” or the KB article for the Root Certificate Program, “KB931125”, and download the latest Root Update package. Root Updates are cumulative, so it should only be necessary to install the latest one to receive all root certificates in the Program. Whether a user, or “relying party”, should trust a root certificate for any particular purpose can be a difficult question. CAs must be on guard against issuing certificates to people who put them to bad use, such as signing malicious software to make it seem more acceptable. CAs should have effective revocation policies and procedures to adequately deal with such certificates. Also, users are expected to scan a CA’s Certificate Practice Statement (CPS) before deciding to trust a certificate - to ensure that acceptance would not cause undue risk to a user’s security, for example. Such documents can be hundreds of pages long though, making user trust decisions complex. Microsoft’s role is to assess CAs and qualify them according to the Program requirements before enabling distribution of their root certificates. We rely upon the judgment of qualified assessors who have themselves been inside the doors of a CA and audited them against publicly available criteria. While our scope of review is relatively narrow and confined to parameters we can verify in advance, our intention is to help customers make difficult trust decisions. ============================================ Here is a little more technical answer: In Windows 2000/XP/2003, we would periodically update the list of Roots in the Microsoft Root Certificate Program (http://technet.microsoft.com/en-us/library/cc751157.aspx) and send out this update via Windows Update. Some customers did not like the behavior of their client computers automatically trusting roots that they did not authorize. This behavior also caused issues with SSL connections once the root list grew beyond 12,000 bytes. See below KB for information: 933430 Clients cannot make connections if you require client certificates on a Web site or if you use IAS in Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb;EN-US;933430 Starting in Windows Vista we no longer import all Root Certification Authorities that are part of the Microsoft Root Certificate Program any longer. Instead when a client attempts to access a resource that it needs to do certificate chaining for it does the following: 1. Looks in the local Intermediate and Root Certification Authorities stores. 2. If it is not located, if the Windows Computer has Internet access it will access an online Microsoft URL to download only the required Root certificate and add it to the Trusted Root Certification Authority store. This is why when you access the website https://www.startcom.org/ in your example that now you have Stardom Certification Authority in the trusted root store. If you want to see this behavior a little more clearly you can enable CAPI2 logging to see this being logged. 1. Open Eventvwr 2. Navigate to: Event Viewer\Applications and Services Logs\Microsoft\Windows\CAPI2\Operational 3. Right click on "Operational" log and select "Enable Log" 4. Access a site. If you have a proxy in your environment you may need to configure WinHTTP to use the proxy server. This can be done using the following command: netsh winhttp set proxy /? To troubleshoot a problem with Automatic Root Updates you can follow this technet content: http://technet.microsoft.com/en-us/library/dd363827(WS.10).aspx If you have clients that do not have access to the internet then you will want to deploy the Trusted Root and any Intermediate certificates via group policy.

Hi Jim, thanks for the good explanation of the process, but could you please also explain how this automatism can be controled? How would I prevent my system from fetching a specific CA because (in contrast to Microsoft) I do not rust this CA? If I would like to, for example, prevent my systems from ever downloading and trusting the COMODO root CA certificate, how would I do that? Best regards, Reiner.

Thanks for a so complete answer, Jim. I understand the reasons for the new procedure, but this creates a new 'problem' to which we must face, as I tried to explain on my first post. We have many customers who come with their own laptop and want to connect to our Wi-Fi network. These laptops are not managed and therefore we can not use mechanisms such as group policies. To ensure the security of the connection we give very clear instructions stating that the PEAP method should only make connections with the specified RADIUS server and only when it has a certificate signed by the root entity we are using. The problem is that if the user hasn't previously downloaded the root certificate (with the procedure you have explained so well), he/she can not select the entity as a trusted root, and not having network (these are users who are setting up the network ) they also have no way to download the certificate. Screenshot: http://personales.upv.es/mimaen/W7/peap1.jpg On the Wi-Fi network, no establishing the DNS name and root certificate for the RADIUS server could permit several types of attacks. So, we have a root certificate approved and included on the Microsoft Root Certificate Program, but we haven't the chance for using it (in this scenario, at least) to guarantee the network connections for our clients. Any ideas for permit a transparent connection setup for the user?