Microsoft Windows Root Certificate Security Issues

Paul Hoffman
Last revision: July 19, 2007

Executive Summary

In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. This prevents a Windows XP SP2 user from declaring a Microsoft-trusted certification authority as untrusted unless the user turns off the Windows component that controls this feature.

Note: Windows Vista works quite differently than Windows XP SP2 in this regard, and has significant but different problems with Microsoft-trusted root certificates: the user cannot mark them as untrusted. The differences between the two versions of Windows are covered in the last section.

Background

"Trusted root certification authorities", commonly called "root certificates", are certificates issued by "certification authorities" or "certificate authorities" or "CAs", which are companies and organizations whose users implicitly trust to identify SSL-based web sites, secure mail senders, and other systems. This identification is done with a public key infrastructure (PKI). For the PKI to work, relying parties (in this case, users who use the web or email) need to inherently trust one or more CAs to provide identification services.

Windows XP SP2 comes with approximately 230 root certificates from approximately 100 reputation providers, banks, governments, and so on. There are many reasons why a user or organization might want to stop trusting a built-in root certificate for authentication, even if the CA is trusted by Microsoft. The most obvious reason is if the certification authority (CA) "goes rogue", meaning that it starts purposely or inadvertently issuing untrustworthy certificates; for example, the owner of the private key might sell it to a criminal organization who could profit from setting up SSL-based web sites that fool users into revealing private information. Other reasons include:

• A company may not trust the company that runs a CA for competitive reasons.
• An agency for one government might not trust a CA that is sponsored by a potentially hostile foreign government.
• The root certificate from a CA uses weaker cryptography for its signature than is allowed by the user's security policy. This is particularly an issue for government agencies with strict cryptography rules.
• A (previously trusted) CA, or its private key, might become compromised.
• The certificate is expired. A similar reason would be that the user knows that the company has gone out of business.

A much more complete description of PKI, root certificates, and related material can be found in Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure, ISBN 0471397024.

The Problem of Hidden Reinstallation in Windows XP SP2

If a user running Windows XP SP2 in its default configuration removes a root certificate that is one that Microsoft trusts, Windows will re-install that root certificate and again start to trust certifcates that come from that root without alerting the user. This re-installation and renewed trust happens as soon as the user visits a SSL-based web site using Internet Explorer or any other web browser that uses the Cryptographic Application Programming Interface (CAPI) built-in to Windows; it will also happen when the user receives secure email using Outlook, Microsoft Mail, or another mail program that uses CAPI, as long as that mail is signed by a certificate that is based on that root certificate.

In essence, this means that the user cannot remove trust of a root certificate unless that user also takes another step (described below) that prevents Windows from taking this action. Further, it also means that a user can be fooled into thinking that they have removed trust in that root certificate when in fact they haven't.

Note that the problems described in this document pertain to users whose software uses CAPI. For example, at the time of this writing, the Mozilla family of software (the Firefox browser and Thunderbird mail client) do not use CAPI, and therefore do not trigger the hidden reinstallation described here. There is no easy way for a user to tell which application software uses CAPI and which software uses other root stores.

For example, assume that a user wants to remove the certificate called "Izenpe.com". (This is not a suggestion that you remove this certificate; it is simply an example.) To do this, select Start → Settings → Control Panel → Internet Options → Content → Certificates → Trusted Root Certification Authorities, scroll down the list, and select the certificate. You will see something like this:

Click the "Remove" button to remove the certificate. You see a dialog that reads:

Choose "Yes" and note that the root certificate is now gone:

If you now go to a SSL-based web site whose identity certificate chains to the root certificate that you just removed, Windows installs that certificate back into the list of Trusted Root Certification Authorities without giving you any warning. Because the certificate was installed again, the SSL-based web site's identity is trusted.

Although this section described certificates that are used for identifying SSL sites, the same actions apply to certificates that are used in signed S/MIME mail messages. Someone malicious who wants to be sure that a particular root certificate that is trusted by Microsoft is installed in a users root store, regardless of whether or not that user has removed the root certificate, can mail the user an S/MIME message whose signature chains to the desired root. If the user runs a mail application that uses CAPI, that root will then be trusted.

A similar problem is that a user cannot know what is in their root store because Windows will add new certification authorities without warning. This is a problem for users because Microsoft adds new certification authorities to its trusted set over time. A user might at one time check the root store to be sure a particular certificate authority is not there, but then have that certification authority added without warning at a later time.

Actions to Prevent Automatic Reinstallation of Removed Roots in Windows XP SP2

Windows XP SP2 by default has a system component called "Update Root Certificates". To turn this component off, select Start → Settings → Control Panel → Add or Remove Programs → Add/Remove Window Components → Update Root Certificates. Deselect the component and click "Next". In some Windows configurations, you must have your Windows installation CD available in order to turn off Update Root Certificates.

After turning off the Update Root Certificates component, Windows XP SP2 will stop silently reinstalling or adding root certificates that you have removed. Windows will also not silently look for root certificates when you go to a SSL-based web site whose identity certificate chains to a root certificate that is not in your root store.

The "Update Root Certificates" action can also be changed if a user is in a Windows policy group. That change needs to be made by the group's policy administrator. Because of this, the user does not generally know whether or not their root certificates are being updated. Also, this only applies to people in policy groups, not all Windows XP SP2 users.

Proposed Action for Microsoft

1. Windows should never install a root certificate without alerting the user. The user should always have the option of not accepting the new root, regardless of whether or not Microsoft trusts that root. The alert to the user should always explain, in simple terms, why the root certificate is being added, why Microsoft trusts the certification authority, why the user might not want to accept the root, and what the consequence of not adding the root certificate would be.

2. Windows should remember when a user has removed a root certificate and, even if the Update Root Certificates component is turned on, should never prompt the user to re-install the certificate. (This is similar to the way that Mozilla currently handles removals and updates for its root certificates.)

3. The certificate deletion dialog described above when deleting certificates has many problems that should be addressed:
   • The dialog should identify the type of certificate that is being deleted; it appears whether or not the certificate is a Microsoft-trusted root or a root that was installed by the user.
   • The dialog appears regardless of whether or not Update Root Certificates is installed.
   • There is no definition for "system root certificates" or "third-party root certificates" easily accessible to the user.
   • The dialog has incorrect information in it: user-installed third-party root certificates are not restored automatically unless they later become trusted by Microsoft.
   • The dialog does not say when or how the root certificates might be restored, such as by receiving a signed email message.

   The dialog should be changed to only appear when appropriate and, in those cases, to clearly specify what the user can do to prevent Windows from taking the action described in the dialog.

4. The user should be able to find the Update Root Certificates program much more easily.
5. The user should be able to turn off and on Update Root Certificates without needing the Windows installation CD.
6. There should be help about the Update Root Certificates component available when the user is adding and removing certificates. That help is currently available from Start → Help and Support, but not from the "?" button in the main Certificates dialog.

Windows Vista and Root Certificate Security Issues

The problems faced by Windows Vista users are quite different than those faced by Windows XP SP2 users. At the time of this writing, Windows Vista comes with only 10 root certificates from 3 reputation providers.

A significant difference between the two types of Windows in the root certificate functionality is that a user cannot delete a certification authority that is trusted by Microsoft. In the Trusted Root Certification Authorities section of the Certificates dialog under Internet Options, when the user selects a certification authority trusted by Microsoft, the "Remove" button is not available.

Windows Vista does act like Windows XP SP2 in that when you try to validate a certificate that chains to a certification authority that is trusted by Microsoft but it is not in your root store, Windows Vista will silently add that certification authority. Like the other certificate authorities trusted by Microsoft, these cannot be removed.

After extensive searching, I could not find a way to remove certificate authorities trusted by Microsoft from Windows Vista. Even if there is a way to do this, there seems to be no equivalent of the Update Root Certificates program that can be turned off. There may be such functionality in Windows Vista, but neither searching in the built-in help nor on the Microsoft support site found anything about such functionality. I tried a few things that people familiar with Vista guessed at, but they were all unsuccessful at getting close to the Windows XP SP2 functionality.

Those users in a Windows policy group may or may not be affected by the policy that is used for Windows XP users; Vista is not listed as an applicable operating system in the Microsoft articles on the subject. This leaves Windows Vista users always having to accept Microsoft's silent updating of their root certificate store.

Revision history:

July 19, 2007: Editorial corrections and enhancements from Pete Resnick, Steve Kent, Michael Singer, and Max Pritikin. Also added a note about having experimented unsuccessfully in Vista.

Please send any comments about to this article to Paul Hoffman <phoffman@proper.com>. I am particularly interested in any updates to the information about Windows Vista.