Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently I was working on recovering data from dead (bricked PSU) Windows XP machine, which included some client certificates installed into IE 6. I plugged in a temporary PSU and tried to export the certificate, only to be told that "these certificates are marked as non-exportable, and thus the private key can not be exported".

I've done some searching around the intertubes, however the only advices I could find were related to pre-install scenarios (ie. there is apparently an option which you can check during the installation to avoid this situation).

My questions would be:

  • Is this a real security measure? It seems to me that you can simply patch the verification logic in IE6 (or the CryptoAPI) and force the export of the certificate / private-key
  • Is there a ready-made tool to do this? (for backup purposes for example)
share|improve this question
up vote 4 down vote accepted

Exporting private keys on certificates that have been marked non-exportable? Uh, how about an article I wrote about a tool called Jailbreak...

share|improve this answer

If is so easy, go ahead, patch the verification logic of IE and CryptoAPI. If you succeed, put out a tool that exports an unexportable private key. For, ahem, backup purposes and such...

First of all the CryptoAPI and friends don't refer to files and memory only. The really strong security is implemented in hardware modules. Even a trivial employee badge and card reader that refuses to export the private key is all but unbeatable for the vast majority of use cases.

Second, even in the file system and memory world of the soft crypto providers there are layers of security. CryptExportKey is just a moniker for the real work. The real cryptographic modules are hardened against a lot of possible attacks. Afaik part of getting the FIPS compliance is to prove that they can detect tampering and such.

share|improve this answer

"Unexportable" means the private key is inaccessible to CryptExportKey(). It might be possible to patch CryptoAPI in memory, but I haven't found any references to it.

There also might be a way to load the registry "hive" in another system and either copy the certificates or edit the "unexportable" bit... but again, no such things on the googlenet.

share|improve this answer


There is a new version of mimikatz that also supports CNG Export (Windows Vista / 7 / 2008 ...)

  1. download (and launch with administrative privileges; trunk version for last version)
  2. privilege::debug (or not if you're already system or target only CryptoApi)
  3. crypto::patchcng (nt 6) and/or crypto::patchcapi (nt 5 & 6)
  4. crypto::exportCertificates and/or crypto::exportCertificates CERT_SYSTEM_STORE_LOCAL_MACHINE

pfx files are passwords protected "mimikatz"

Old post:

Maybe can you try another tool with other private keys functions : "mimikatz", it export other keys that other cannot export (non exportable, medium protected, orphan, etc..) The "bit" is not altered on system file, only the program context is altered :) For example, an user (not administrator) can export his own protected / non exportable keys without particulars rights.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.