First, the problem (reported by others on the forums):

CryptAcquireContext fails in CAPIProvider.CreateInternalHandle, the SspiProvider.CryptAcquireContext call failing to return a handle. The same code in a Console or WinForms app works fine.

Second, the fix I made: There's an "if" statement in case System.Environment.UserInteractive returns false on NT-based OS. I have removed SecurityConstants.CRYPT_MACHINE_KEYSET from the assignment to "flags", leaving ONLY SecurityConstants.CRYPT_SILENT.

I'm NO CryptoAPI GENIUS, but I have a feeling this "if" was added as a patch for other problems related to ASP.NET. If I'm using the Mentalis Security Library solely for implementing SSL in an FTP library, can I assume I NEVER want to acquire the context with CRYPT_MACHINE_KEYSET? Any other comments on such a fix?

If your FTP library can be used from an ASP.NET page, you cannot assume that.
The Machine keyset is used for processes that do not have access to a user profile. According to MSDN, you should always use this keyset for services and ASP pages.

But CryptAcquireContext fails. What does that mean? Should I add some special privilege or rights to the ASPNET user or aspnet_wp.dll process? What is required in order to perform a minimal SSL connection with an FTP server?

The problem should be fixed in the current version of the library. Whether you have to use CRYPT_MACHINE_KEYSET or not depends on your ASP configuration, so the library now simply tries both configurations and selects one that works.