Hello Kim, I'm out of town this week. Please fill the problem into bugzilla and I'll look into it next week.
Thanks On Tue, 2006-02-14 at 10:44 +0100, Hellan.Kim KHE wrote: > Hi again > > We have been investigating this some more. Apparently the problem is "working > as intended". Why it is so, is described here: > http://support.microsoft.com/default.aspx?scid=KB;EN-US;322371 > > The solution is, instead of using: > RSA rsa = RSA.Create(); > use this: > CspParameters CSPParam = new CspParameters(); > CSPParam.Flags = CspProviderFlags.UseMachineKeyStore; > RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(CSPParam); > or maybe this: > RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(); > rsa.UseMachineKeyStore = true; > > I don't think there is any way around this, other than to fix the Mono code > as you (Sebastien) suggested. > Fortunately I think it is only in a few files that you do the RSA.Create(), > and call ImportParameters() afterwards. > > If you decide to make the fix, we would be happy to test it with our COM > wrapped assembly immediately. > If you want a bugzilla report to initiate it, let me know and I will make one. > > Thanks, > Kim > > > -----Oprindelig meddelelse----- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne af Hellan.Kim KHE > Sendt: 10. februar 2006 09:35 > Til: [EMAIL PROTECTED] > Cc: [email protected] > Emne: SV: [Mono-list] Problem with crypto in assembly wrapped in COM > > Hi Sebastien, > > Thank you for answering. > I didn't mean that Mono should adapt our code, it was just to show > something that worked for us. > We will try to see if we can find a solution for this problem. > I'll let you know what we find. > > /Kim > > -----Oprindelig meddelelse----- > Fra: Sebastien Pouliot [mailto:[EMAIL PROTECTED] > Sendt: 8. februar 2006 15:24 > Til: Hellan.Kim KHE > Cc: [email protected] > Emne: Re: [Mono-list] Problem with crypto in assembly wrapped in COM > > Hello Kim, > > On Wed, 2006-02-08 at 13:24 +0100, Hellan.Kim KHE wrote: > > We have an assembly containing crypto functionality (X.509 > certificates, > > PKCS#12, PKCS#7...) from Mono.Security.dll. So far it has been running > > fine in both WinForm and Webform environments (.NET 2.0). > > We have had to wrap this assembly in COM to allow it to be run from > old > > ASP platforms. > > Nice. As far as I know you're the first to use Mono.Security.dll via > COM. I'm glad it works (even if not completely ;-) > > > We now get the following errors when the .NET/COM component is called > > from a webpage: > > > > Error: exception=System.Security.Cryptography.CryptographicException: > > The system cannot find the file specified. > > > > at > System.Security.Cryptography.Utils.CreateProvHandle(CspParameters > > parameters, Boolean randomKeyContainer) > > at > > > System.Security.Cryptography.RSACryptoServiceProvider.ImportParameters(R > > SAParameters parameters) > > at Mono.Security.Cryptography.PKCS8.PrivateKeyInfo.DecodeRSA(Byte[] > > keypair) > > at Mono.Security.X509.PKCS12.AddPrivateKey(PrivateKeyInfo pki) > > at Mono.Security.X509.PKCS12.ReadSafeBag(ASN1 safeBag) > > at Mono.Security.X509.PKCS12.Decode(Byte[] data) > > at Mono.Security.X509.PKCS12.LoadFromFile(String filename, String > > password) > > .... > > .... > > > > > > I have a theory what is happening... > > In DecodeRSA() you have the following lines: > > > > RSA rsa = RSA.Create (); > > rsa.ImportParameters (param); > > > > I have seen before that ImportParameters() had problems in > > webapplications, because it apparently tries to access some keystores, > > that the IIS user does not have access to. A COM wrapped assembly > > probably have even less rights than a standalone assembly. > > This is the code I used instead in my application to solve the > problem: > > Yes. Even if the .NET API makes key containers optional (for importing > or using keyparis), MS implementation is dependent on CryptoAPI, which > is dependent on the key stores, which depends on the current user (and > its permissions). > > > CspParameters CSPParam = new CspParameters(); > > CSPParam.Flags = CspProviderFlags.UseMachineKeyStore; > > RSACryptoServiceProvider rsa; > > if(System.Web.HttpContext.Current == null) // WinForm > > rsa = new RSACryptoServiceProvider(); > > else // WebForm - Uses Machine store for keys > > rsa = new RSACryptoServiceProvider(CSPParam); > > rsa.ImportParameters(rsaParam); > > This will work for your own code. However Mono can't adopt this as this > would make Mono.Security.dll depends on System.Web (and create more > circular dependencies on Mono). > > > Has anyone else had this problem and do you have a solution for it? > > This is a well known problem (on Windows + .NET crypto). IIRC there is a > few knowledge base article on the subject. It is also a common question > on MS newsgroups. > > > Maybe you have to change some security settings in .NET or elsewhere > to > > allow this...I don't know. > > Google should find them easily (kb + newsgroups). There may be a "fix" > for this. IIRC there was one .config trick that I think it works only > for WSE stuff... but I may be wrong. > > > I'm a bit stuck since I can't control what Mono is doing. > > Please do look at Google and see if and how this can be fixed. It would > be nice to report the finding on this mailing-list (i.e. giving Google > another chance to index the answer ;-). > > If a fix isn't possible then I think I could change Mono.Security's > source code to trap the first ImportParameters for a > CryptographicException, then re-try the ImportParameters using the > UseMachineKeyStore (as a second/last chance). _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
