I am working on Private Key archival with a Windows Server 2008 R2 Certificate Authority. On the client side, I am interested in knowing which Crypto API function calls are made by the windows processes when the client requests for an archival enabled certificate. In particular, my focus is to track the function calls listed here, http://msdn.microsoft.com/en-us/library/aa922849.aspx , present in Advapi32.dll .
I have tried out the windbg/cdb script here ( http://blogs.msdn.com/b/alejacma/archive/2007/10/31/cryptoapi-tracer.aspx ). I attached it to mmc.exe while making a certificate request but I couldn't detect any CSP calls being made during the process. I also tried requesting certificate through certreq.exe but windbg couldn't trace any CSP calls. I have also tried other forms of tracing as mentioned in the stackoverflow thread titled "Monitoring application calls to DLL"
Which windows process/service I need to attach to, in order to find how these calls are being made? Is it possible to trace whenever a function call is made, irrespective of which process makes it?
Any suggestions on how to trace these CSP calls?
advapi32.dll used to contain cryptography implementation some time ago, but now this functionality has been moved to cryptsp.dll. Windows team sometimes moves implementation of public methods from one DLL into another. See more examples on this in The Old New Thing Blog. Advapi32.dll simply calls into corresponding functions in cryptsp.dll.
Apparently certificate APIs in mmc that you were trying to debug are calling directly into cryptsp.dll. Example from a call stack on Windows 8:
0:000> k
Child-SP RetAddr Call Site
00000000`0059c278 000007fd`6c1b7d8b CRYPTSP!CryptAcquireContextA
00000000`0059c280 000007fd`6c1ace66 CRYPT32!I_CryptGetDefaultCryptProv+0xbc
00000000`0059c2d0 000007fd`6c1ae1b3 CRYPT32!FastCreateCtlElement+0x4a6
00000000`0059c4e0 000007fd`6c1a248a CRYPT32!CreateCtlElement+0x23
00000000`0059c530 000007fd`6c1a2297 CRYPT32!CreateStoreElement+0x139
00000000`0059c610 000007fd`6c1abaa4 CRYPT32!LoadStoreElement+0x244
00000000`0059c6f0 000007fd`6c1a2c76 CRYPT32!OpenFromRegistry+0x39e
00000000`0059c950 000007fd`6c1a2e7c CRYPT32!OpenAllFromRegistryEx+0x96
00000000`0059c9d0 000007fd`6c1a394b CRYPT32!I_CertDllOpenRegStoreProv+0xfc
00000000`0059ca20 000007fd`6c196926 CRYPT32!I_CertDllOpenSystemRegistryStoreProvW+0x28b
00000000`0059cb20 000007fd`6c1a3b72 CRYPT32!CertOpenStore+0x296
00000000`0059cba0 000007fd`6c1a3dc2 CRYPT32!OpenPhysicalStoreCallback+0xc2
00000000`0059cc70 000007fd`6c1a4512 CRYPT32!EnumPhysicalStore+0x648
00000000`0059ce00 000007fd`6c196926 CRYPT32!I_CertDllOpenSystemStoreProvW+0x162
00000000`0059cee0 000007fd`6c1a3b72 CRYPT32!CertOpenStore+0x296
00000000`0059cf60 000007fd`6c1a3dc2 CRYPT32!OpenPhysicalStoreCallback+0xc2
00000000`0059d030 000007fd`6c1a4512 CRYPT32!EnumPhysicalStore+0x648
00000000`0059d1c0 000007fd`6c196926 CRYPT32!I_CertDllOpenSystemStoreProvW+0x162
00000000`0059d2a0 000007fd`47371a27 CRYPT32!CertOpenStore+0x296
00000000`0059d320 000007fd`47363611 certmgr!CCertStore::GetStoreHandle+0xc7
Notice, advapi32.dll is not even present in the call stack.
So the solution for you would be to put breakpoints directly on the functions in cryptsp.dll. E.g.:
> bu CRYPTSP!CryptAcquireContextW
> bu CRYPTSP!CryptAcquireContextA
> bu CRYPTSP!CryptDecrypt
> ... and so on ...
> g