After a system reboot (Win7 x64), an application reported that it couldn't access a file in an EFS-encrypted directory.
- Accessing via programs gave "Access denied".
- Permissions were normal and fine.
- The problem affected 2 more, random-selected files.
- There were no relevant changes or issues in a long time.
So this looked like this question, and indeed, the file was encrypted to a different certificate according to the certificate thumbprint shown in the dialog that pops up when you click "Details" in the "Advanced Attributes" dialog.
But here's the strange thing:
- Opening the "Advanced Attributes" dialog (from the file properties dialog) took ~10 seconds and 100% CPU, every time, and only for this file.
Stack traces obtained via ProcessHacker were full of "efscore.dll", "bcrypt.dll", "crypt32.dll", and such. certmgr.msc
showed a new EFS certificate that I didn't create myself. It was valid from 3 days ago, and its thumbprint was the one I saw on the file I couldn't access.- The export wizard allowed to export that new EFS certificate, but it gave an error message half-way ("Key not valid for use in specified state".) and the file it created didn't actually contain the selected certificate but a different one.
- On a cloned copy of the system, after a while, the file was accessible again and its contents intact! I inspected the thumbprint of the certificate associated with it, and this time it was the thumbprint of my usual certificate, and not any more that of the newly-created certificate.
So, this makes me wonder about the reliability of EFS.
- Why was a new certificate silently created and apparently used for the encryption of a few files?
- Why did the certificate associated with the file appear to change?