Nope - I don't understand this one. According to everything I've seen, error should not be 0. However - looking at what you've done, I can't see a problem. Basically - if Windows reports an error, but there is no error code, disable AES. If there is something more fundamental wrong, the next call to check for RSA will fail, and an exception will still be thrown. I.e. this is still a safe path to take.
I've just made this change to the library in CVS. (Although I didn't add the check for NTE_PROV_TYPE_NO_MATCH as I think this means something else is wrong - i.e. the string passed in is bodgy?)
As an aside - I don't have access to a whole bunch of different Windows machines, so any feedback like this is extremely useful. Thanks!
Cheers, Berin
Andrzej Matejko wrote:
Hi,
Recently, during xsec tests on w2k I have noticed that on some workstations WinCAPICryptoProvider(provDSSName, provRSAName) fails on second CryptAquireContext( if (!CryptAcquireContext(&m_provRSA,NULL, provRSAName, PROV_RSA_AES, CRYPT_VERIFYCONTEXT)) ). And the most straneg things is, that GetLastError() return 0. So, I have to change : if( (error == NTE_PROV_TYPE_NOT_DEF) || ( error == NTE_PROV_TYPE_NO_MATCH) ) { into: if( (error == NTE_PROV_TYPE_NOT_DEF) || ( error == NTE_PROV_TYPE_NO_MATCH) || ( error==0) ) {
After this everything works perfectly. And here is the question: is it a bug in xsec or have I done something wrong? (In my application I call WinCAPICryptoProvider with "Microsoft Strong Cryptographic Provider" as provRSAName.
Regards, andrzeJ