[Mono-dev] Remothing through HTTPS

[Yngve Zackrisson]

Sorry bothering again but I have more questions / troubles.

> >    Is there any other way to get the key?.
> 
> You can get a list of the private keys (there can be more than one)
> available in the PKCS#12 file by using the Keys property.
> 

1) Just a clarification. 
   The Keys is a ArrayList of RSA objects (key.RSA). Right ?.



2) I did not mention that I also wanted the X509Certificate 
   from the PKCS#12 file in Mono / Linux.
   I can get that through the Mono PKCS12 class, 
   but the type is Mono.Security.X509.X509Certificate.
   Mono's SslServerStream's constructor (for instance) requires 
   System.Security.Cryptography.X509Certificates.X509Certificate.
   Is there any conversion function between these types ?.
 


3) When using the PKCS12 on Win32 i got an exception in mscorlib.
   Does Mono.Security.dll requires a special corlib or is 
   the error a configuration error ?.



   Below is the details of the error (manually  retyped):
   >>>
   An unhandled exception of type 'System.TypeLoadException' occured in 
   mono.security.dll

   Additional information: Could not load type 
   System.Security.Cryptography.HMAC from assembly mscorlib, 
   Version = 1.0.500.0, Cuture=neutral, 
   PublicKeyToken=b77a5c561934e089.

   On the console I got (manually retyped): 

   Unhandled Exception: System.TypeLoadException: Could not load type   
   System.Security.Cryptography.HMAC from assembly mscorlib,    
   version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
      at Mono.Security.X509.pkcs12.MAC(Byte[] password, Byte[] salt, 
   Int32 iterations, Byte[] data)
      at Mono.Security.X509.PKCS12.Decode(Byte[] data)
      at Mono.Security.X509.LoadFromFile(String filename, String    
   password) 
      at SslHttpServer.SslHttpServer.Main(String[] args) in    
   c:\SharpDevelop Projects\HTTPS-PKCS12-Tunnel\MonoSslHttpServer\ 
   Main.cs:line 40    
   Press any key to continue . . . 
   <<<


Regards 


     
// Yngve Zackrisson.


> > B) Server certificate to the Mono / Linux store: 
> > 
> >    Just checking if I got things right:
> > 
> >    I user the command: 
> > 
> >    $ mono /usr/lib/mono/certmgr.exe -add -c -m CA cacert.cer 
> > 
> >    $ mono /usr/lib/mono/certmgr.exe -add -c -m Trust server-certkey.cer 
> 
> You should have a certmgr script (that calls mono on the installed
> certmgr.exe) that would be simpler to type.
> 
> >    to load the CA cert (cacert.cer with in DER format) and 
> >    to load the server cert 
> >    (server certificate request are first signed and 
> >    then the server-cert.pem and server-key.pem are concatenated 
> >    with the cat command to server-certkey.pem 
> >    witch is then converted to server-certkey.cer in DER format).
> 
> ???
> server-cert.pem should contain your server certificate.
> DON'T CONCATENATE your private key with it. The certificate store isn't
> designed to keep private keys safe.
> 
> >    The CN should be the same as hostname.
> 
> yes
> 
> >    Do you find any error in the above procedure?
> 
> No. The Trust is done on a self-signed (root) certificate - which is
> generally a CA certificate (non self signed certificates goes into the
> CA store).
> 
> _Assuming_ that your CA certificate is self-signed then all you have to
> do is:
> 
> certmgr -add -c -m cacert.cer
> 
> The server certificate doesn't have to be in the store as you supply it
> to the server.
> 
> >    Does the Mono SSL handle incomming httprequests automatically 
> >    or do I have to handle (for instance) the authentication in 
> >    the custom channel? (If so, any code to look at? XSP?).
> 
> Mono's SSL doesn't (directly) understand HTTP - it sits lower in the
> network stack.
> 
> Recent XSP versions are SSL enabled.
> 
> 
> > C) Client side certificate handling in Win32.
> > 
> >    I use "HttpWebRequest.ClientCertificates.Add(x509Certificate)" 
> >    to set the client certificate.
> > 
> >    Below you wrote: 
> > 
> > > Using client certificates in this (remoting) setup may prove a little
> > > more challenging as Fx1.x X509Certificate class has no notion of a
> > > private key associated with the certificate. This may be fixed by doing
> > > a custom remoting channel that use Mono.Security.dll (where you'll have
> > > a callback to supply the private key for your client certificate).
> > > 
> >    
> >    Since I am no expert in this area (just have to try to be one 
> >    due to the current lack of SSL security .NET Remoting) 
> >    I just wonder if anyone can direct me to what to do.
> >    I have read (implemented) the MS articles about custom channels 
> >    and MS authentication, so I pretty much understand custom channels. 
> >    I ques that it is only the authentication I have to try to 
> >    implement in the custom channel?
> 
> and I'm no expert in remoting ;-) but I would try setting up a "classic"
> SSL channel first - then worry about about client certificates. At least
> at this stage you'll have some code to show to get more help.
> 
> >    Are there any open source code (.NET Mono C#) - about 
> >    client side certificate authentication - I can download and read?.
> 
> The XSP version released with 1.1.9 supports client-side certificates.
> 
> > 
> > 
> > 
> > Regards 
> > 
> > 
> > 
> > Yngve Zackrisson
> > 
> > 
> > 
> > On Wed, 2005-09-07 at 13:39, Sebastien Pouliot wrote:
> > > Hello Yngve,
> > > 
> > > On Wed, 2005-07-09 at 11:15 +0200, Yngve Zackrisson wrote:
> > > > Hi all.
> > > > 
> > > > I am doing an remoting application 
> > > > and have a Win32 Client with MS .NET v1.1
> > > > and a Linux (Fedora Core 3 x86) Server with Mono 1.1.8.3.
> > > > 
> > > > The different clients will call the remote objects methods 
> > > > on the server. 
> > > > Among other things the clients will upload a file to the server. 
> > > > I (now) only uses "normal" calls to upload a file - 
> > > > no "callbacks" any more.
> > > > The server will be located at our place.
> > > > The clients will be users of "services", running on our server.
> > > > The remote objects is currently hosted by an Console application, 
> > > > but is planned to be hosted by a Windows service (on Linux / Mono :-)).
> > > > I have gotten this working with HTTP.
> > > > 
> > > > I now will try to do this with HTTPS (on port 443), 
> > > > to get a secure tunnel between the client and the server.
> > > > 
> > > > We would like to use SSL with both encryption and authentication, 
> > > > through x509 certificates.
> > > > The certificates should (preferable) be self signed.
> > > > 
> > > > >From my testings and readings I have found that: 
> > > > 1) My Win32 client uses Tls.
> > > > 2) The Win32 client certificates should be:
> > > >    a) Set in the ClientCertificates property of the HttpWebRequest.
> > > >    b) The client certificate must be installed in 
> > > >       the LOCAL_MACHINE registry hive.
> > > >    (Se: KB895971 at http://support.microsoft.com/?kbid=895971).
> > > > 3) .NET prefer the DER format (called .cer) 
> > > >    but may also use the .p12 format.
> > > > 4) From the Microsoft .NET documentation, 
> > > >    I have found support only for certificate authentication 
> > > >    through ASP.NET/IIS-hosting - In MS .NET v1.1.
> > > > 5) There is some support for SSL in Mono, 
> > > >    and I have succeeded to install certificates in Mono through certmgr 
> > > >    (but I may have done it wrong. No real test yet).
> > > 
> > > 
> > > > What I wonder is weather this approach gonna work with .NET Remoting 
> > > > and with different Win32 MS .NET clients calling a Linux Mono server?.
> > > 
> > > Using client certificates in this (remoting) setup may prove a little
> > > more challenging as Fx1.x X509Certificate class has no notion of a
> > > private key associated with the certificate. This may be fixed by doing
> > > a custom remoting channel that use Mono.Security.dll (where you'll have
> > > a callback to supply the private key for your client certificate).
> > > 
> > > > Do I have to customize any part of the SSL handshake?.
> > > 
> > > No. SSL/TLS is a negotiating protocol. You supply the certificates and
> > > the rest gets done (well pretty much).
> > > 
> > > More details on SSL are available in the FAQ
> > > http://www.mono-project.com/FAQ:_Security
> > > 
> > > > On the remote objects methods, I would like to have 
> > > > access checks on the users .NET Roles.
> > > > Is it possible to impersonate the principal and add .NET Roles 
> > > > to that principal when the remote objects is hosted in 
> > > > a Console application or a Windows service (in Linux / Mono)?.
> > > 
> > > You can't impersonate (in the win32 way) if your communication channel
> > > doesn't support it (e.g. SSPI) - so this works only for _some_ win32
> > > stuff.
> > > 
> > > You can always "mimic" the impersonation by transferring the identity in
> > > a custom remoting channel (and setting the IPrincipal of the remote
> > > object yourself). There are a lot of example for doing this on the net.
> > > Alternatively you can create a new IPrincipal instance based on the
> > > client certificate used by client client.
> > > 
> > > Lastly when using roles be sure to use imperative demands (e.g.
> > > IPrincipal.IsInRole) and not declarative security attributes
> > > (PrincipalPermission) unless you activate the security manager
> > > (--security).
> > > http://www.mono-project.com/CAS
> > > 
> > > > Further, I am not really sure about how to set up the certificates 
> > > > on the Mono server for SSL.
> > > 
> > > See the FAQ and/or do a "man certmgr" in a terminal.
> > > 
> > > > I assume the the certificates should be placed in the machine store.
> > > 
> > > That depends on what will be using the certificate.
> > > 
> > > > I have the certificates in DER (.cer) format.
> > > > Should the CA certificate be placed in the CA store 
> > > > or in the Trust store?. Any more to think about?.
> > > 
> > > Self-signed certificates goes to the trusted store.
> > > The CA store is for intermediate CA certificates.
> > > 
> > > > I assume that the server certificate should be placed 
> > > > in the Trust store (of the machine store).
> > > > I hope this is right.
> > > 
> > > The machine store is handy if you don't know under which identity (user)
> > > your program is gonna be executed (or if it may be executed by multiple
> > > users on the same system). Otherwise keep your stuff in the user store.
> > 
>