On a system running Widows XP;sp2 we fail to get a crypto service provider when testing from a web service, yet the same code works fine when tested with a windows app.

The web service and windows apps both work on several other systems to which we have deployed the test project.

We fail in the CryptographyStructure.cs code in the CreateInternalHandle at this code:

if (SspiProvider.CryptAcquireContext(ref handle, container, null, m_Providers[i], flags) == 0) {...

which ends up calling:
[DllImport(@"advapi32.dll", EntryPoint="CryptAcquireContextA"....

Have tried using impersonation in web.config so we have same user as the Windows App, and have tried to find a security setting on the mis-behaving machine that differs from the other machines but no luck.

This is v1.0.13.715 of Org.Mentalis.Security.dll

I'm experiencing a similar problem (on Windows Server 2003 R2) from within an Enterprise Service component which is running under a dedicated user account. I don't have the problem if I impersonate Network Service, and also don't get the problem (apparently regardless of the user) when running in a Windows app or console app.

When calling a Certificate's PublicKey property, it looks like there's a call to CAPIProvider.Handle. Then inside the CAPIProvider class before it calls CryptAcquireContext, it checks Environment.UserInteractive and the platform info, and sets some flags. I suppose that from a windows app, these flags wouldn't get set, so maybe that would make a difference. I'm not sure why there'd be a difference between Network Service and a dedicated user account though, unless Network Service has permissions that my dedicated user account doesn't (with respect to the CryptAcquireContext call).

Anyway, I don't guess that really solves anything, but I thought I would add my two cents in case it might help someone solve the problem.

Daniel

have you SQL server 2005 beta2 installed?