This article has been archived. It is offered "as is" and will no longer be updated.
The Encrypting File System (EFS) smartcard certificate implementation in Windows Vista ignores the Enhanced Key Usage extension if the extension does not specify EFS. In this situation, a certificate may be selected that is not intended for data encryption. Therefore, data may be lost if a Disaster Recovery Agent (DRA) is not configured or if the noncompliant certificate that was previously selected is not retained after it expires.
This hotfix is scheduled to be included with Windows Server 2008 Service Pack 2 (SP2) and with Windows Vista Service Pack 2 (SP2).
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
After you apply this hotfix, you must make the following changes to the registry:
Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press ENTER.
Locate and then right-click the following registry subkey:
Right-click RequireValidEKU, and then click Modify.
In the Value data box, type 1, and then click OK.
Note Set the value to 1 to require a valid EKU.
Exit Registry Editor.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
To support single sign-on (SSO) in Windows Vista for EFS, the following decision flow is used to find an EFS-compliant certificate on the smartcard that is used to log on:
If the logon certificate has the EFS Extended Key Usage (EKU) (OID of "126.96.36.199.4.1.3188.8.131.52"), verify that it is usable for EFS, and then select it as the current EFS key.
Enumerate the certificates on the smartcard. (You are searching for one that has the EFS EKU.) If you find one, verify that it is usable for EFS, and then select it as the current EFS key.
If no certificate has the EFS EKU, search for a certificate that has either a Key Usage (KU) of CERT_KEY_ENCIPHERMENT_KEY_USAGE or no KU defined. If you find one, verify that it is usable for EFS, and then select it as the current EFS key.
If none of these steps yields an EFS-compliant certificate, the logon smartcard cannot be used for SSO.
Follow these steps only if a current EFS key is not already defined.
The meaning of the phrase "usable for EFS" depends both on policy and on the certificate/key capabilities. In summary, this phrase refers to one or more of the following conditions:
The key that is specified for the certificate’s private key has the AT_KEYEXCHANGE flag.
If the smartcard cached key mode is specified in policy, the private key can be used to derive the cached key. This involves a signing operation.
If the smartcard cached key mode is not specified in policy, the key must be able to perform an RSA encryption/decryption operation.
If smartcards are required by policy, the key provider must be of the type CRYPT_IMPL_REMOVABLE.
The RSA key size must be at least 1024 bits.
If self-signed certificates are disabled by policy, the certificate must be issued by a CA.
For more information about the Encrypting File System, visit the following Microsoft Web site: