The EFS component driver has always been limited in how and when it selects an available digital certificate for the user:
  • Once EFS has selected a digital certificate for encryption, it will continue to use that certificate until the certificate expires or it is "archived"
    • If the certificate is later revoked, EFS won't respond - EFS does not check revocation for a certificate it is already using
    • If another EFS certificate is enrolled or imported, EFS won't respond - even if the certificate has longer keys, was enrolled using better archival and recovery policy, or us due to expire later than the currently-selected certificate
  • EFS will only look for a different certificate if the currently-selected certificate has expired when EFS attempts to encrypt a new file
  • Even when EFS looks for a "different certificate", it will select the first available certificate that matches its requirements
    • On Windows 2003, XP and 2000, EFS requires that the certificate has a matching private key, that the certificate hasn't expired, and that the certificate contains the EFS EKU (i.e. the OID corresponding to "Encrypting File System" (1.3.6.1.4.1.311.10.3.4) )
    • On Windows Vista and later, EFS requires that the certificate has a matching private key, that the certificate hasn't expired, and that the certificate contains the encryption Key Usage
  • Note that EFS does not perform any complex sorting or selection logic when there are more than one valid EFS certificates - the first valid certificate that it finds, it will select.
    • e.g. if the first certificate found has a 1024-bit key length and was enrolled from the Basic EFS certificate template, and the second certificate has 2048-bit keys and was enrolled from a v2 certificate template, EFS will still select the first certificate (so long as it meets the validation critieria above)

This all means that migrating a user from a self-signed or BasicEFS certificate to a v2 template-enrolled certificate is significantly more of a challenge than it first appears:
  • When a self-signed EFS certificate is already configured, it isn't possible to automatically migrate the user to use a v2 template-enrolled EFS certificate
    • If the user runs (or you add to a script) the CIPHER /K command, at best the user will enroll for and starting using a BasicEFS template-enrolled certificate. This command is hard-coded to the BasicEFS certificate template, and will not attempt to use or enroll an EFS certificate from a v2 template.
    • If the user auto-enrolls for a v2 EFS certificate, even if the v2 template is configured to supersede all other EFS certificates, this enrollment operation won't archive the self-signed certificate, and won't update the user's EFS policy with the new certificate
  • When a BasicEFS certificate is already configured, it isn't possible to automatically migrate the user to use a v2 template-enrolled EFS certificate:
    • As above, CIPHER /K won't enroll for a v2 template EFS certificate
    • If the user auto-enrolls for a v2 EFS certificate that is configured to supersede the BasicEFS template, the user's BasicEFS certificate will be archived in the user's personal certificate store (sometimes called the MY store), but the user's EFS policy won't be updated with the new certificate. EFS will continue to use the BasicEFS certificate until that certificate expires - at which time, EFS will automatically select and start using the already-enrolled v2 EFS certificate (according to KB 295680)

Last edited Aug 1, 2007 at 1:00 AM by MikeSL, version 6

Comments

No comments yet.